lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 23 Feb 2007 00:21:30 +0800
From:	"Antonino A. Daplas" <adaplas@...il.com>
To:	Giuseppe Bilotta <giuseppe.bilotta@...il.com>
Cc:	James Simmons <jsimmons@...radead.org>,
	Luca Tettamanti <kronos@...ple.it>,
	linux-fbdev-devel@...ts.sourceforge.net,
	Andrew Morton <akpm@...l.org>, Dave Airlie <airlied@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta wrote:
> On 2/22/07, Antonino A. Daplas <adaplas@...il.com> wrote:
> >
> > Ah, my fault.  Apply this patch on top.
> 
> We're getting closer! The patch now works, and the dmesg has the following info:

Okay.

> 
> 
> ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKA] -> GSI 11 (level,
> low) -> IRQ 11
> nvidiafb: Device ID: 10de0112
> fbmon: The EDID Block of Manufacturer: SHP Model: 0x138e is known to be broken,
> fbmon: trying to fix monitor timings
> nvidiafb: EDID found from BUS2
> ========================================
> Display Information (EDID)
> ========================================
>    EDID Version 1.3
>    Manufacturer: SHP
>    Model: 138e
>    Serial#: 0
>    Year: 1990 Week 0
>    Display Characteristics:
>       Monitor Operating Limits: From EDID
>            H: 30-75KHz V: 60-60Hz DCLK: 170MHz
>       Digital Display Input
>       Sync:
>       Max H-size in cm: 30
>       Max V-size in cm: 23
>       Gamma: 2.20
>       DPMS: Active no, Suspend yes, Standby yes
>       RGB Color Display
>       Chroma
>          RedX:     0.599 RedY:     0.335
>          GreenX:   0.313 GreenY:   0.552
>          BlueX:    0.150 BlueY:    0.145
>          WhiteX:   0.313 WhiteY:   0.328
>       First DETAILED Timing is preferred
>    Detailed Timings
>       160 MHz 1600 1664 1856 2112 1200 1201 1204 1250 -HSync -VSync
> 
>    Supported VESA Modes
>       Manufacturer's mask: 0
>    Standard Timings
>       1600x1200@...z
> ========================================
> nvidiafb: CRTC 1 is currently programmed for DFP
> nvidiafb: Using DFP on CRTC 1
> nvidiafb: Panel size is 1600 x 1200
> nvidiafb: Panel is TMDS
> nvidiafb: MTRR set to ON
> nvidiafb: Flat panel dithering disabled
> Console: switching to colour frame buffer device 200x75
> nvidiafb: PCI nVidia NV11 framebuffer (32MB @ 0xE0000000)
> 
> 
> 
> 
> However, I'm still getting the same snowy effects, which doesn't come
> as a surprise since the actual mode timings used are just the same ...
> 

Yes, because the EDID has only 1 mode entry. But now you can use 'fbset
1024x768-60' (or any mode smaller than 1600x1200-60) for example and it
should work.  You might want to change  vfmin and vfmax to 59 and 61
respectively just to get leeway for mode calculation errors. This is in
drivers/video/fbmon.c, particularly b[5] and b[6] in this code:

	case FBMON_FIX_TIMINGS:
		printk("fbmon: trying to fix monitor timings\n");
		b = edid + DETAILED_TIMING_DESCRIPTIONS_START;
		for (i = 0; i < 4; i++) {
			if (!(edid_is_serial_block(b) ||
			      edid_is_ascii_block(b) ||
			      edid_is_monitor_block(b) ||
			      edid_is_timing_block(b))) {
				b[0] = 0x00; 
				b[1] = 0x00;  
				b[2] = 0x00;
				b[3] = 0xfd;   
				b[4] = 0x00;
				b[5] = 60;   /* vfmin */
				b[6] = 60;   /* vfmax */
				b[7] = 30;   /* hfmin */
				b[8] = 75;   /* hfmax */
				b[9] = 17;   /* pixclock - 170 MHz*/
				b[10] = 0;   /* GTF */
				break;
			}

			b += DETAILED_TIMING_DESCRIPTION_SIZE; 
		}

Also try doing fbset 640x480-60, 800x600-60, 1024x768-60 and
1280x1024-60, and if they displayed correctly, we can add these modes to
your EDID block.

Tony

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ