linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Antonino Daplas <adaplas@pol.net>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Kendall Bennett <KendallB@scitechsoft.com>,
	Linux Fbdev development list
	<linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: [ANNOUNCE]: VM86 Daemon
Date: 01 Apr 2003 17:41:10 +0800	[thread overview]
Message-ID: <1049189944.1009.61.camel@localhost.localdomain> (raw)
In-Reply-To: <1049185774.593.46.camel@zion.wanadoo.fr>

On Tue, 2003-04-01 at 16:29, Benjamin Herrenschmidt wrote:
> 
> Once the fbdev can provide, upon request, the EDID and probing info
> (some cards can tell you if something is connected even without
> providing an EDID, like on the S-Video output, or on the VGA output
> with a non-DDC capable monitor), we need some consistent API to
> retreive that from, userland at least
> 
> Then, we need fbdev to "validate" modes based on those EDID infos
> (via fbmon ?).
> 

How I'm currently doing it with the extended vesafb driver is this:

1. construct a database of video modes in struct fb_videomode format
based on all the modes given by the EDID.  This database can be passed
to fb_find_mode() in modedb.c to select the best video mode.  If the
monitor's operating limits are unknown, then the driver is restricted to
using only modes listed by the database.

2. If the monitor's operating limits are known (again via EDID), modes
can be easily validated.  There's already working code for this in
fbmon.c -- fb_validate_mode().  

3. If the monitor is GTF-capable, then referring to the database can
actually be skipped, and modelines will just be computed using the VESA
GT formula.  Again, the code is already existent in fbmon.c --
fb_get_mode().  

I've also extended EDID parsing in fbmon.c.  Here's a sample output:

========================================
Display Information (EDID)
========================================
   EDID Version 1.3
   Manufacturer: VSC Model: 2007 Serial#: 16843009
   Year: 2001 Week 47
   Display Characteristics:
      Analog Display Input: Input Voltage - 0.700V/0.300V
      Sync: Separate Composite Sync on Green
      Max H-size in cm: 38
      Max V-size in cm: 30
      Gamma: 2.40
      DPMS: Active yes, Suspend no, Standby no
      RGB Color Display
      First DETAILED Timing is preferred
   Standard Timings
      1280x10240@60Hz
      1280x1024@75Hz
      1152x864@75Hz
      1024x768@75Hz
      832x624@75Hz
      800x600@75Hz
      640x480@75Hz
      640x480@60Hz
   Supported VESA Modes
      720x400@70Hz
      640x480@60Hz
      640x480@67Hz
      640x480@72Hz
      640x480@75Hz
      800x600@56Hz
      800x600@60Hz
      800x600@72Hz
      800x600@75Hz
      832x624@75Hz
      1024x768@60Hz
      1024x768@70Hz
      1024x768@75Hz
      1280x1024@75Hz
      1152x870@75Hz
      Manufacturer's mask: 0
   Detailed Monitor Information
      108 MHz 1280 1328 1440 1688 1024 1025 1028 1066 +HSync +VSync

      Serial No     : A0Y014710490
      HorizSync     : 30-82 KHz
      VertRefresh   : 50-75 Hz
      Max Pixelclock: 140 MHz
      Monitor Name  : VG191
========================================

Tony



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

  reply	other threads:[~2003-04-01 10:25 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-31  9:53 [ANNOUNCE]: VM86 Daemon Antonino Daplas
2003-04-01  0:07 ` Jon Smirl
2003-04-01  0:27   ` Kendall Bennett
2003-04-01  1:27     ` Antonino Daplas
2003-04-01  8:29       ` Benjamin Herrenschmidt
2003-04-01  9:41         ` Antonino Daplas [this message]
2003-04-01 11:34           ` Benjamin Herrenschmidt
2003-04-01 13:38             ` Antonino Daplas
2003-04-01 13:53               ` Benjamin Herrenschmidt
2003-04-01 15:32                 ` Antonino Daplas
2003-04-01 15:22               ` Jon Smirl
2003-04-01 16:25                 ` Antonino Daplas
2003-04-01 16:44                   ` Benjamin Herrenschmidt
2003-04-01 18:30                   ` Small API change Benjamin Herrenschmidt
2003-04-01 20:10                     ` Geert Uytterhoeven
2003-04-01 22:03                       ` Benjamin Herrenschmidt
2003-04-02 22:01                         ` James Simmons
2003-04-02 22:11                           ` Benjamin Herrenschmidt
2003-04-01  1:04   ` [ANNOUNCE]: VM86 Daemon Antonino Daplas
2003-04-01  4:01     ` Jon Smirl
2003-04-01  9:41       ` Antonino Daplas
     [not found]         ` <20030401120835.GA30421@skunk.convergence.de>
2003-04-01 13:38           ` [directfb-dev] " Antonino 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=1049189944.1009.61.camel@localhost.localdomain \
    --to=adaplas@pol.net \
    --cc=KendallB@scitechsoft.com \
    --cc=benh@kernel.crashing.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).