All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Antonino A. Daplas" <adaplas@hotpop.com>
To: linux-fbdev-devel@lists.sourceforge.net,
	Andrew Walrond <andrew@walrond.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Chad Daelhousen <cd9@cse.buffalo.edu>
Subject: Re: Rivafb won't work with DVI connector
Date: Wed, 24 Nov 2004 06:44:13 +0800	[thread overview]
Message-ID: <200411240638.51261.adaplas@hotpop.com> (raw)
In-Reply-To: <200411232053.28741.andrew@walrond.org>

[-- Attachment #1: Type: text/plain, Size: 2577 bytes --]

On Wednesday 24 November 2004 04:53, Andrew Walrond wrote:
> On Tuesday 23 Nov 2004 19:59, Geert Uytterhoeven wrote:
> > No, this will use the BIOS to switch to a 1280x1024 mode before starting
> > the kernel. Remember that Tony told you the panel size is set up by the
> > BIOS. If that's really the case, it should help.

When the input is digital, it seems that there are other registers that are
programmed besides that of the CRTC registers.  During the setup, some
of the registers are actually read by the code, and these are the panel width
and height.  The rest of the registers we don't know about (no
documentation).

So the safe approach is to accept what the BIOS programmed for us, use
scaling for res < panel size, and reject all res > panel size. If we know
how to program the rest of the registers, then this should be no problem.

Therefore, using vesafb to pre-program the registers for higher resolutions
means that the BIOS can setup the undocumented registers for us so we can
have a limit greater than 1024x768.

If the input is analog, then all that is required are the CRTC registers. The
panel size is actually not read in analog input. And since we know what to
do with CRTC registers, even if the preferred mode is 1024x768 but the EDID
tells us that it can support timings other than that, we can still use that
mode.

In short, the main difference is the type of input and lack of documentation.

>
> Hi Geert,
>
> I got that. I guess I'm asking whether the problem is self imposed by our
> driver by rejecting modes > panel size. Ie could we just ignore the panel
> size and allow any EDID supported modes?

As I've said, you can try to ignore the registers pre-programmed by the
BIOS, but I don't know the side effects of this.

> Or, is it the video card that in any case would not allow us to set modes >
> panel size?

No, it's the undocumented registers that prevents us from using modes >
panel size.

>
> Chad explains it well in his email.

Yes, what Chad said is true if the input is analog.  It's a different story if
the input is digital.

Anyway, attached is a patch that prevents an oops if the boot mode is
illegal.  It will still limit your resolution to panel size if input is digital.

Tony

BTW: How does X behave if the input is digital.  Does it accept modes
greater than panel size?  If it does, then the documentation is actually
there.  I'll look at the X code again.  And I'll probably do some googling
on this.  If you happen to encounter any kind of programming info about
this, let me know also.

Thanks for testing.



[-- Attachment #2: nvidiafb2-inc4.diff --]
[-- Type: text/x-diff, Size: 1672 bytes --]

diff -Nru a/drivers/video/nvidia/nvidia.c b/drivers/video/nvidia/nvidia.c
--- a/drivers/video/nvidia/nvidia.c	2004-11-23 06:01:00 +08:00
+++ b/drivers/video/nvidia/nvidia.c	2004-11-24 06:15:15 +08:00
@@ -1101,15 +1101,16 @@
                     | FBINFO_HWACCEL_YPAN
 	            | FBINFO_MISC_MODESWITCHLATE;
 
-	info->var = nvidiafb_default_var;
-	if (mode_option) {
-		fb_find_mode(&info->var, info, mode_option, specs->modedb,
-			     specs->modedb_len, NULL, 8);
-	} else if (specs->modedb != NULL) {
+	fb_videomode_to_modelist(info->monspecs.modedb,
+				 info->monspecs.modedb_len,
+				 &info->modelist);
+	fb_var_to_videomode(&modedb, &nvidiafb_default_var);
+
+	if (specs->modedb != NULL) {
 		/* get preferred timing */
 		if (specs->misc & FB_MISC_1ST_DETAIL) {
 			int i;
-
+			
 			for (i = 0; i < specs->modedb_len; i++) {
 				if (specs->modedb[i].flag & FB_MODE_IS_FIRST) {
 					modedb = specs->modedb[i];
@@ -1121,16 +1122,18 @@
 			modedb = specs->modedb[0];
 		}
 		info->var.bits_per_pixel = 8;
-		fb_videomode_to_var(&info->var, &modedb);
+		fb_videomode_to_var(&nvidiafb_default_var, &modedb);
 	}
 
+	if (mode_option)
+		fb_find_mode(&nvidiafb_default_var, info, mode_option,
+			     specs->modedb, specs->modedb_len, &modedb, 8);
+
+	info->var = nvidiafb_default_var;
 	info->fix.visual = (info->var.bits_per_pixel == 8) ?
 		FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_DIRECTCOLOR;
 	info->pseudo_palette = par->pseudo_palette;
 	fb_alloc_cmap(&info->cmap, 256, 0);	
-	fb_videomode_to_modelist(info->monspecs.modedb,
-				 info->monspecs.modedb_len,
-				 &info->modelist);
 	fb_destroy_modedb(info->monspecs.modedb);
 	info->monspecs.modedb = NULL;
 

  reply	other threads:[~2004-11-23 22:44 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-19 11:37 Rivafb won't work with DVI connector Andrew Walrond
2004-11-19 22:08 ` Antonino A. Daplas
2004-11-20 15:52   ` Andrew Walrond
2004-11-22  0:11     ` Antonino A. Daplas
2004-11-22  9:23       ` Andrew Walrond
2004-11-22  9:43         ` Andrew Walrond
2004-11-22 22:13           ` Antonino A. Daplas
2004-11-22 23:47             ` Andrew Walrond
2004-11-22 23:54               ` Andrew Walrond
2004-11-23  1:50               ` Antonino A. Daplas
2004-11-23 12:32                 ` Andrew Walrond
2004-11-23 14:28                   ` Antonino A. Daplas
2004-11-23 15:09                     ` Andrew Walrond
2004-11-23 15:18                       ` Antonino A. Daplas
2004-11-23 16:08                         ` Andrew Walrond
2004-11-23 17:07                           ` Antonino A. Daplas
2004-11-23 18:01                             ` Andrew Walrond
2004-11-23 18:26                               ` Antonino A. Daplas
2004-11-23 19:00                                 ` Andrew Walrond
2004-11-23 19:07                                   ` Andrew Walrond
2004-11-23 19:23                                 ` Andrew Walrond
2004-11-23 19:59                                   ` Geert Uytterhoeven
2004-11-23 20:53                                     ` Andrew Walrond
2004-11-23 22:44                                       ` Antonino A. Daplas [this message]
2004-11-23 23:59                                         ` Andrew Walrond
2004-11-24 22:38                                         ` Andrew Walrond
2004-11-23 20:21                                   ` Chad Daelhousen
2004-11-24 23:01                                 ` Andrew Walrond
  -- strict thread matches above, loose matches on Subject: below --
2004-11-25  0:07 Antonino A. Daplas
2004-11-25 15:27 ` Andrew Walrond
2004-11-25 21:16   ` Antonino A. Daplas
2004-11-26 14:09   ` Antonino A. Daplas
2004-11-27 12:40     ` Andrew Walrond
2004-11-27 18:29       ` Michel Dänzer
2004-11-27 22:35         ` Andrew Walrond
2004-11-27 22:43       ` Antonino A. 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=200411240638.51261.adaplas@hotpop.com \
    --to=adaplas@hotpop.com \
    --cc=andrew@walrond.org \
    --cc=cd9@cse.buffalo.edu \
    --cc=geert@linux-m68k.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 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.