[mythtv] MythTV 0.15 Port for FreeBSD

[Stacey Son]

Matt Zimmerman wrote:

>I had a look at your patches:
>
>patch-NuppelVideoPlayer.cpp
>  This seems to just wrap everything with #ifdef USING_IVTV with another
>  #ifdef for FreeBSD, which is unnecessary.  Instead, don't define
>  USING_IVTV in settings.pro.
>
>  
>
I forgot to take out the "#ifndef __FreeBSD__"  around the "#ifdef 
USING_IVTV".    Before I got videoout_ivtv.cpp patched I just #ifndef'ed 
out all the support for the PVR-350.   Note that the cxm driver does not 
support the PVR-350 so videoout_ivtv.cpp has not been tested.   In 
short, this patch is not needed now and can be ignored.

>patch-RingBuffer.cpp
>  There already exists a generic macro which implies the availability of
>  fdatasync, standardized by POSIX.  I committed a change to use it, so
>  this patch should no longer be necessary.
>  
>
I'll look for this and back out the patch.

>patch-channel.cpp, patch-fifowriter.cpp
>  Can you explain these?  Why doesn't it work on FreeBSD as-is?
>
>  
>
For channel.cpp I get a strange compile time error without the cast:

  channel.cpp: In function `int signalStrengthATSC_v4l2(int, int)':
  channel.cpp:474: error: no matching function for call to 
`clamp(__s32&, int,
     int)'
  *** Error code 1

I haven't really figured out the correct way to handle this but casting 
it to an int seems to work. :) Note that FreeBSD is using g++ version 
3.3.3. 

For fifowriter.cpp, S_IREAD, S_IWRITE, S_IRGRP,  and so on are defined 
in stat.h for FreeBSD.

>patch-ivtv-ext-api.h
>  Not sure what to do about this yet.
>
>  
>
ivtv-ext-api.h hardcodes the ioctl values rather than letting the 
_IOR/_IORW macros define them.   Of course,  FreeBSD and Linux define 
these macros differently and FreeBSD has problems knowing what kind of 
ioctl arg to expect with the hardcoded values.  Hopefully, the need for 
this patch will go away when the IVTV driver becames a little more mature.

>patch-mainserver.cpp
>  hunk 1: should be the same for linux; commited without #ifdefs
>  hunk 2: statfs again; fixed in the same way as the others
>  hunks 3-4: why does this thread need such a huge stack?  maybe there is a
>             better way to fix it
>  
>
That is a very good question.   The answer might be in the QT code 
somewhere.   BTW,  I don't know if these threads actually need 256K each 
but I do know that the default stack size (64K) doesn't work.   With the 
default stack size the thread stack gets blown when doing live TV.  If 
you can think of a better solution I would like to know.

Thanks,

-stacey.