Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 27 Apr 1998 20:36:20 -0400
From:      Randall Hopper <rhh@ct.picker.com>
To:        tomppa@fidata.fi, Amancio Hasty <hasty@rah.star-gate.com>
Cc:        freebsd-multimedia@FreeBSD.ORG
Subject:   Re: problem capturing video with BT848/Haughpage Win/Tv
Message-ID:  <19980427203620.A28932@ct.picker.com>
In-Reply-To: <13626.37007.633346.611739@zeta.fidata.fi>; from Tomi Vainio on Mon, Apr 20, 1998 at 03:02:23AM %2B0300
References:  <13626.35483.87697.62123@zeta.fidata.fi> <199804192348.QAA03334@rah.star-gate.com> <13626.37007.633346.611739@zeta.fidata.fi>

next in thread | previous in thread | raw e-mail | index | archive | help
Tomi Vainio:
 |I already have these:
 |options         SYSVSHM
 |options         "SHMMAX=(SHMMAXPGS*PAGE_SIZE+1)"
 |options         SHMALL=8192
 |options         SHMMAXPGS=8192
 |options         SHMMIN=2
 |options         SHMMNI=128
 |options         SHMSEG=32

I only have:
     options              SYSVSHM

but I build a kernel with your SHM option set and didn't have any problems
with direct video or Shm XImages mode.

 |cputime         unlimited
 |filesize        unlimited
 |datasize        16MB
 |stacksize       8MB
 |coredumpsize    unlimited
 |memoryuse       30MB
 |memorylocked    10MB
 |maxproc         64
 |descriptors     64

More liberal than mine (defaults).  I suspect these can't be right though:

cputime         unlimited
filesize        unlimited
datasize        22528 kbytes
stacksize       8192 kbytes
coredumpsize    unlimited
memoryuse       30720 kbytes
descriptors     64 
memorylocked    10240 kbytes
maxproc         64 

 |Amancio Hasty:
 | > And why you didn't report this earlier??
 | > 
 |I reported this same problem with Xaccel server on July 1997.

I remember.  Seems like we never did get to the bottom of it and I'd about
chalked it up to Xaccel.  But it's a given now that it's not.

 |BTW.  I still have to use this to get picture inside window
 |tvcapture.c line 1509:
 |        video.addr      = x->base_addr + (g.y * x->pitch + g.x + 256) * Bpp;

Yeah, I still don't get this.  Of course, this effectively says that your
framebuffer is 256 pixels offset past where the XFree86 DGA extension says
it is.  Does this work in all color depths (16bpp, 24bpp, 32bpp?)

On the surface, sounds like an XFree86 DGA bug.  You might check that
"base_addr" contains the same number that is printed by the XFree86 startup
output (startx -- -probeonly) for the base address of your linear frame
buffer.  Of course, it may be reporting it wrong both places.

Randall

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-multimedia" in the body of the message



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