Framebuffer questions

Framebuffer questions

[Ondrej Zajicek]

Hello

I have several questions about fbdev. I already read FB-FAQ, most docs
in Documentation/fb/*, linux/fb.h and some messages in archive of this
mailing list.

- I understood that if i want to change videomode then i should set
  all items in struct fb_var_screeninfo, call ioctl FBIOPUT_VSCREENINFO,
  driver considers wanted parameters and if exactly this mode or mode
  with more bits_per_pixel or greater some bitfield.length is supported,
  then mode is changed, otherwise change is rejected. If change is
  successfull, then i should call ioctl FBIOGET_VSCREENINFO and
  FBIOGET_FSCREENINFO to get information about real framebuffer
  structure. Is this correct?

- Should i really set all fields? For example offset and msb_right
  parts of red, green, blue and transp. I usually don't care of this
  so i want to set some DONT_CARE value. Or are these items always
  ignored so i needn't set anything?
  
- If i have to supply complete mode timings for videomode change
  why there is modedb.c and mode lines stored inside drivers?

- I see there is FB_TYPE_TEXT mode (assume for standard text mode).
  what should i set in struct fb_var_screeninfo to get this mode?
  If i grep drivers/video for it, i get it occurs only in vga16fb.
  Is there some deep reason for this or just programmers of other
  fb drivers don't care about text mode?
  
- Is there some possibility to get list of possible framebuffer
  videomodes? Or just list of possible 'structural' framebuffer
  configurations (type,visual,bpp,r/g/b)? (i hope that usually this is
  ortogonal to resolution and timings setting - suppose have enough ram).
  I know about FB_ACTIVATE_TEST but use iterative binary search to
  find all video modes isn't sane idea :-)

- Is there description of fb sysfs interface anywhere? 

- Is there description of specific framebuffer formats for
  various FB_TYPE_* and FB_AUX_*  anywhere?

- I found that with vga16fb i can access just first plane.
  Is it possible to switch planes from userspace and without
  interaction with VGA registers?

- What exactly is supposed to do FB_SYNC_BROADCAST ?

- In include/fb.h there is:

#define FB_VISUAL_PSEUDOCOLOR           3       /* Pseudo color (like atari) */

  Is there some deep sense in remark '(like atari)' or is this well-known
  basic palette visual mode?

I hope i can get some answers or hints.

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago@mail.cz, jabber: santiago@njs.netlab.cz)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Framebuffer questions

[Antonino A. Daplas]

Ondrej Zajicek wrote:
> Hello
> 
> I have several questions about fbdev. I already read FB-FAQ, most docs
> in Documentation/fb/*, linux/fb.h and some messages in archive of this
> mailing list.
> 
> - I understood that if i want to change videomode then i should set
>   all items in struct fb_var_screeninfo, call ioctl FBIOPUT_VSCREENINFO,
>   driver considers wanted parameters and if exactly this mode or mode
>   with more bits_per_pixel or greater some bitfield.length is supported,
>   then mode is changed, otherwise change is rejected. If change is
>   successfull, then i should call ioctl FBIOGET_VSCREENINFO and
>   FBIOGET_FSCREENINFO to get information about real framebuffer
>   structure. Is this correct?

Yes but with exceptions.  For drivers with fixed modes, ie, vesafb, it
will always return the current fb_var_screeninfo whether the values
are greater/lesser than requested.

It is also possible that some of the fields are automatically set by the
driver, ie if requesting bits_per_pixel = 16, the rgba lengths and offsets
may automatically be set.

> 
> - Should i really set all fields? For example offset and msb_right
>   parts of red, green, blue and transp. I usually don't care of this
>   so i want to set some DONT_CARE value. Or are these items always
>   ignored so i needn't set anything?

Some of the fields are ignored, but you can never know which. To be on the
safe side, just get the current fb_var_screeninfo, use that as your
template, change the fields you want to change then pass it back to the
driver.

>   
> - If i have to supply complete mode timings for videomode change
>   why there is modedb.c and mode lines stored inside drivers?

Usually, these entries are used only on startup. Some drivers support
built-in internal mode tables, some use standard algo's (GTF, CVT) to
compute the mode timings. With these drivers, passing xres and yres is
usually enough. 

> 
> - I see there is FB_TYPE_TEXT mode (assume for standard text mode).
>   what should i set in struct fb_var_screeninfo to get this mode?
>   If i grep drivers/video for it, i get it occurs only in vga16fb.
>   Is there some deep reason for this or just programmers of other
>   fb drivers don't care about text mode?

This particular flag means that the driver is in text mode (ie, not
in graphics mode).  One driver, matroxfb in 2.4, has this functionality 
(by setting bits_per_pixel = 0), the driver goes to text mode (ie
vgacon like mode).

No driver implements this in 2.6 though, although we have the infra-
structure for this.

>   
> - Is there some possibility to get list of possible framebuffer
>   videomodes?

Hard to say with the display mode.  You can examine

/sys/class/graphics/fb[x]/modes

for a subset of modes supported.

>   Or just list of possible 'structural' framebuffer
>   configurations (type,visual,bpp,r/g/b)? (i hope that usually this is
>   ortogonal to resolution and timings setting - suppose have enough ram).
>   I know about FB_ACTIVATE_TEST but use iterative binary search to
>   find all video modes isn't sane idea :-)

No list.  But it shouldn't be too hard.  You only need get the  current
fb_var_screeninfo and only change bits_per_pixel most of the time to do
the search. Some drivers also examine green.length (ie if bits_per_pixel = 
16 and green.length is 5, RGB555, if 6, RGB565).

> 
> - Is there description of fb sysfs interface anywhere? 

None yet, it's still in a state of flux. Most of the entries
there though are counterparts of the fields in fb_var_sreeninfo and
a few are nonfunctional.

> 
> - Is there description of specific framebuffer formats for
>   various FB_TYPE_* and FB_AUX_*  anywhere?

None, except the comments in fb.h.  Most of the entries there
are for drivers that support nonlinear formats, and FB_AUX_ tells
you the type of interleaving for interleaved planes.  Only a few drivers
set these flags (amifb, atafb (broken in 2.6), vga16fb and matroxfb).

> 
> - I found that with vga16fb i can access just first plane.
>   Is it possible to switch planes from userspace and without
>   interaction with VGA registers?

I don't think so.  But you can set vga16fb for 8-bit linear format.

> 
> - What exactly is supposed to do FB_SYNC_BROADCAST ?
> 

Use standard TV timings.

> - In include/fb.h there is:
> 
> #define FB_VISUAL_PSEUDOCOLOR           3       /* Pseudo color (like atari) */
> 
>   Is there some deep sense in remark '(like atari)' or is this well-known
>   basic palette visual mode?
> 

No, it's not specific to atari, this is your basic indexed mode.

Tony


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Framebuffer questions

[Ondrej Zajicek]

Thank you for answers. Perhaps i found some time to write
some API documentation.

On Thu, Mar 16, 2006 at 09:20:42AM +0800, Antonino A. Daplas wrote:
> > - If i have to supply complete mode timings for videomode change
> >   why there is modedb.c and mode lines stored inside drivers?
> 
> Usually, these entries are used only on startup. Some drivers support
> built-in internal mode tables, some use standard algo's (GTF, CVT) to
> compute the mode timings. With these drivers, passing xres and yres is
> usually enough. 

So with these drivers it is not possible to set non-standard timings
(because other timing arguments are always ignored)? Or are there some
(standard or driver/specific) way to differentiate between set and
non-set additional timing arguments?

> > 
> > - What exactly is supposed to do FB_SYNC_BROADCAST ?
> > 
> 
> Use standard TV timings.

So it is rather equvalent to set standard TV timing values to appropriate
timing arguments and setting csync?

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago@mail.cz, jabber: santiago@njs.netlab.cz)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Framebuffer questions

[Antonino A. Daplas]

Ondrej Zajicek wrote:
> Thank you for answers. Perhaps i found some time to write
> some API documentation.
> 
> On Thu, Mar 16, 2006 at 09:20:42AM +0800, Antonino A. Daplas wrote:
>>> - If i have to supply complete mode timings for videomode change
>>>   why there is modedb.c and mode lines stored inside drivers?
>> Usually, these entries are used only on startup. Some drivers support
>> built-in internal mode tables, some use standard algo's (GTF, CVT) to
>> compute the mode timings. With these drivers, passing xres and yres is
>> usually enough. 
> 
> So with these drivers it is not possible to set non-standard timings
> (because other timing arguments are always ignored)?

As long as the modeline is valid, drivers tend to accept them. It is only
when you passed invalid timings that drivers will

a. reject;
b. compute with GTF/CVT; or
c. get the nearest modeline from its internal table.

Tony


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

framebuffer questions

[Scott D. Davilla]

I'm tracking a X11 hang/video corruption problem. I'm not a Linux 
framebuffer expert so I'm asking for input.

Hardware is an AppleTV (yes, an AppleTV). This is an EFI based 
pentium-m with intel 945GM chipset with nvidia 7300.

Linux boots and I get console output. X11 works but when displaying 
720p or 1080i MPEG2 content using xvmc, I get random application 
hangs (requiring a kill to the app) and random green macro block 
video corruption.  A similar BIOS based ITX system  configured with 
identical kernel/rootfile system never hangs or has video corruption.

The differences are EFI vs BIOS and imacfb vs vesafb.

EFI does not have any dynamic interaction with the kernel or app 
level. The only time EFI comes into play is mapping memory and 
acpi/smbios address structures. And with these EFI is not doing 
anything, the kernel  EFI routines are using the passed EFI memory 
structures. All timing/runtime EFI services are disabled/remapped to 
non-EFI routines. I've even remapped the EFI structures into e820 
structures in an experimental bootloader that boots the kernel is a 
similar fashion as ELILO does for the 2.6.24 kernels and still get 
hangs/video corrution. So I don't think it's related to EFI booting.


Going over the imacfb source, I've noticed a few issues that might be 
causing hidden problems.

1) "info = framebuffer_alloc(sizeof(u32) * 16, &dev->dev)" is used to 
allocate memory for the framebuffer info structure (struct fb_info 
*info).

struct fb_info is greater than 16 * sizeof(u32) so it seems this 
should be "info = framebuffer_alloc(sizeof(struct fb_info), 
&dev->dev)" or imacfb is going to be read/writing beyond what was 
allocated. Side note efifb.c has this same code as it was derived 
from imacfb.


2) "request_mem_region(imacfb_fix.smem_start, size_total, "imacfb")" 
uses size_total and "ioremap(imacfb_fix.smem_start, 
imacfb_fix.smem_len)" uses imacfb_fix.smem_len. I guess the intent 
here is request memory for the largest video buffer size supported 
but only map the current video buffer size. There's a complicated 
logic sequence above the request_mem_region call that uses magic 
numbers to try to compute and pad the various sizes.

This seems in error. The current video buffer size is 
"imacfb_defined.yres * imacfb_fix.line_length", and the max size is 
screen_info.lfb_size. Should these not be used directly and all the 
sizing logic voodoo removed.

3) imacfb (and efifb) do not any removal routines for unloading the 
module. So what happens when X11 takes over? Should there be an 
removal routine for unloading? The console video buffer is still 
mapped (screen_base). How does X11 know not to use this area? What 
does X11 do regarding the console framebuffer when it runs and it is 
does not unlaod the console module, how does it avoid using the 
console mapped video memory?

Thanks
Scott


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: framebuffer questions

[Geert Uytterhoeven]

On Sat, 9 Feb 2008, Scott D. Davilla wrote:
> 1) "info = framebuffer_alloc(sizeof(u32) * 16, &dev->dev)" is used to 
> allocate memory for the framebuffer info structure (struct fb_info 
> *info).
> 
> struct fb_info is greater than 16 * sizeof(u32) so it seems this 
> should be "info = framebuffer_alloc(sizeof(struct fb_info), 
> &dev->dev)" or imacfb is going to be read/writing beyond what was 
> allocated. Side note efifb.c has this same code as it was derived 
> from imacfb.

That's OK. `sizeof(u32) * 16' is the amount of extra private memory used by
the driver, in addition to sizeof(struct fb_info).

> 3) imacfb (and efifb) do not any removal routines for unloading the 
> module. So what happens when X11 takes over? Should there be an 
> removal routine for unloading? The console video buffer is still 
> mapped (screen_base). How does X11 know not to use this area? What 
> does X11 do regarding the console framebuffer when it runs and it is 
> does not unlaod the console module, how does it avoid using the 
> console mapped video memory?

X and imacfb will coexist and use the same memory.

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/