Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 16 Dec 1995 16:26:30 +0100 (MET)
From:      Luigi Rizzo <luigi@labinfo.iet.unipi.it>
To:        james@miller.cs.uwm.edu (Jim Lowe)
Cc:        tinguely@plains.nodak.edu, hackers@freebsd.org
Subject:   meteor driver bug
Message-ID:  <199512161526.QAA00317@labinfo.iet.unipi.it>
In-Reply-To: <199512111637.KAA18548@miller.cs.uwm.edu> from "Jim Lowe" at Dec 11, 95 10:37:24 am

next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
I finally got a copy of the data sheets for the Philips video
chipset used in the meteor.

I found out one bug in the current driver.  Also I have some
suggestions for the driver. I might be able to work on them after
the 22nd, unless you do it first. I would also like to make some
cosmetic changes to the driver in order to remove some NTSC-related
magic numbers that are spread over the code.

******************** meteor.c [driver] ********************************

BUG: around line 1072 of the driver, the following code:

                *p++ = buf;     /* even y or even RGB */
                                /* set end of buffer location */
                *(p+36)  = *(p+35) = buf + mtr->alloc_pages * PAGE_SIZE;

    the last line should read 

                *(p+34)  = *(p+35) = buf + mtr->alloc_pages * PAGE_SIZE;

    as the pointer (p) has been already incremented. Due to this
    bug, we are going to write past the end of the 7116 registers,
    with unknown effects.


FEATURE: at offset 0x3c in the 7116, it would be preferable to
    set the "Field Toggle" bit. This enables the 7116 to simulate the
    presence of an interlaced image even with non-interlaced images. It
    should help with VTRs and should not harm otherwise. Thus I would
    change the init value from

	/* 0x3c */      0x00000103,     /*  9:8   *RW   Reserved (0x0)

    to

	/* 0x3c */      0x00000107,     /*  9:8   *RW   Reserved (0x0)

FEATURE: the 'correct' values for regs 01-05 of the 7196,
    according to the data sheets, should be the following:

/* 01 */        0x30,   /* 7:0  Horizontal Sync Begin for 50hz */
/* 02 */        0x00,   /* 7:0  Horizontal Sync Stop for 50hz */
/* 03 */        0xe8,   /* 7:0  Horizontal Sync Clamp Start for 50hz */
/* 04 */        0xb6,   /* 7:0  Horizontal Sync Clamp Stop for 50hz */
/* 05 */        0xf4,   /* 7:0  Horizontal Sync Start after PH1 for 50hz */

    I tried them with a 50Hz PAL camera, and they seem to work fine.
    They could replace my previous suggestion.


PROPOSAL: whith moving images, mixing samples from two frames produces
    a very unpleasant visual effect (basically, one frame is shifted
    with respect to the previous one). Moreover, this mix produces
    (spatial) high frequency components which make the compression
    algorithms work less efficiently. My proposal is to acquire
    single frames by default, and use both frames only in the case
    of the highest resolution images (e.g. 640x480 or 768x576).
    This can be done without loss of resolution. It requires some
    simple changes to the METEORSETGEO ioctl, and possibly to
    the interrupt handling routine.


	Luigi
====================================================================
Luigi Rizzo                     Dip. di Ingegneria dell'Informazione
email: luigi@iet.unipi.it       Universita' di Pisa
tel: +39-50-568533              via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522              http://www.iet.unipi.it/~luigi/
====================================================================



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512161526.QAA00317>