On Wed, Jan 02, 2002 at 09:23:12PM +0100, Peter Surda wrote:
> On Wed, Jan 02, 2002 at 07:08:08PM +0100, Zdenek Kabelac wrote:
> > From doc for Matrox card it looks like rather simple thing to select image
> > borders and I would expect the same for ATI
> Unfortunately the ATI tv encoder chips are undocumented (because macrovision
> blah blah), thats why it aint so easy.
Hmm I've though there is full documentation for ATI chips as well.
Actually Macrovision bit is documented in MGA spec
(but it's not said it's Macrovision :))
>
> Here comes API proposal:
>
> /proc/something/list -> list of cards and short descriptions, one per line,
> and enough info for X or generally a userspace app to find out which card it
> is currently working with
> /proc/something/x/info (x being card #) -> some additional info, like if the
> current mode is interlaced
> /proc/something/x/freq -> current frequency, so we can automagically find out
> if the "24 fps video on PAL TV" situation is occuring. It could either be
> measured with TSC on every vbi, or with simple clock ticks, say "how many vbis
> have happened in the last 10 or 100 clock ticks?" (this might cause a short
> fscking up upon videomode switch, but doesn't require a pentium+ CPU, think
> about other architectures).
> /proc/something/x/eject -> spit out the card out of the case :-)
I've been rather thinking that all important info could be
retried via read -
e.g. mga_vid counts amount of interrupts between HZ jiffies
and returns current interrupt number and HZ as two 4bytes integers.
I'm not sure if it makes real sence to play with proc for now -
it's not that much usable for program I would say
> /dev/something (character device) -> block on read till vbi occurs on one
> card, and then will spit out a few bytes telling what (vbi end, vbi begin,
> nuthing) on a even/odd frame happened on which card. I think we don't need
> ioctls. Or perhaps one
I'm using IOCTL for IRQ_ON IRQ_OFF
But it might be turned on/off with open/close automaticaly
(it already made with close anyway)
> I think this is not very much code (and more importantly VERY LITTLE
> card-dependent code) and hence I propose this beast to compile into a single
Actually you still need detection of the graphics card - thus it's
not as that independed as it might look for the first time.
> module. The only problem I see is closed-source driver and I couldn't care
> less about it. If there aren't even docs on how to detect vbi and interlacing,
> screw the card.
I've not checked how easy is to detect if odd or even fields are displayed...
> mga_vid and ati_vid are currently used for YUV scaler. I think this stuff
> belongs to userspace, because XvShmPutImage already does this optimally
I hope there is no aplication which would be copying 0.5MB in kernel mode ?????
At least there is no such think with mga_vid as far as I know.
--
.''`. Which fundamental human right do you want to give up today?
: :' : Debian GNU/Linux maintainer - www.debian.{org,cz}
`. `' Zdenek Kabelac kabi@{debian.org, users.sf.net, fi.muni.cz}
`- Resistance is futile. You all will be packaged
_______________________________________________
Avifile mailing list
[EMAIL PROTECTED]
http://prak.org/mailman/listinfo/avifile
