linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Antonino A. Daplas" <adaplas@gmail.com>
To: linux-fbdev-devel@lists.sourceforge.net
Cc: santiago@mail.cz
Subject: Re: Framebuffer questions
Date: Thu, 16 Mar 2006 09:20:42 +0800	[thread overview]
Message-ID: <4418BD6A.9080600@gmail.com> (raw)
In-Reply-To: <20060315211022.GA4474@localhost.localdomain>

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

  reply	other threads:[~2006-03-16  1:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-15 21:10 Framebuffer questions Ondrej Zajicek
2006-03-16  1:20 ` Antonino A. Daplas [this message]
2006-03-16 10:17   ` Ondrej Zajicek
2006-03-16 21:26     ` Antonino A. Daplas
  -- strict thread matches above, loose matches on Subject: below --
2008-02-09 21:12 framebuffer questions Scott D. Davilla
2008-02-10 11:11 ` Geert Uytterhoeven

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=4418BD6A.9080600@gmail.com \
    --to=adaplas@gmail.com \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=santiago@mail.cz \
    /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).