Known bugs in Zapping, don't report them
----------------------------------------

Zapping 0.7 bugs, need more work later:
* Video size isn't always right on startup.
* Spinslider minimum sizes.
* Zapzilla: what's v4lx doing on standard change?
  Changing the video standard breaks vbi decoding.
* Select composite, quit, restart, back at "television". Problem: channels
  have a video input parameter, and selecting composite does not
  switch the channel, so on restart the channel's input is restored. We
  could have a "null" channel, but what about e.g. ttx bookmarks?
* Prefs does not apply screenshot add toolbar option. Seems to be
  another gtk_widget_show/hide toolbar item problem.
* capture.c/retrieve_frame() fails to convert a previously
  successfully requested format (specifically YUV420 to YUYV
  requested by plugins/mpeg/mpeg.c).
* When a/v recording is started under high system load the
  timestamps may differ too much, triggering the mp1e
  "cannot sync" check and aborting Zapping.
* App specific toolbar_style is pointless. Gnome can already
  handle that for us, see gnome-app-helper.c. Or right click
  on the toolbar dock bevel. Note also Ctrl-Cursor to move
  the toolbar around.
* 2003-11-27 From windowed overlay to fullscreen w/automatic vidmode hang
  on RH at switch_mode (PREVIEW) -> z_set_window_bg -> calloc segv.
  Circumstances might be coincidental, it doesn't happen predictable.
  valgrind --skin=addrcheck was inconclusive:
   ==17270== Invalid memory access of size 4
   at 0x40424ABB: gconf_engine_all_dirs (in /usr/lib/libgconf-2.so.4.1.0)
   by 0x4042A0E9: gconf_client_preload (in /usr/lib/libgconf-2.so.4.1.0)
   by 0x404292A3: gconf_client_add_dir (in /usr/lib/libgconf-2.so.4.1.0)
   by 0x40279941: (within /usr/lib/libgnomeui-2.so.0.200.0)
   Address 0x0 is not stack'd, malloc'd or free'd
   No recipient addresses found in header
  Program segv'ed before window opened.
* 0.7 seems to run slower than 0.6, must profile.
* Overlay needs a review.
* Prefs toolbar style menu does not update when config changes
  (should it?) and selection cannot be canceled.
* mpeg plugin doesn't link with libdivx-20030428.
  Undefined reference to __start_cp_handler, __eh_rtime_match.
  g++ doesn't help, no .a|.o|.so found. Where the fsck are they defined??
* Edited channels, clicked ok, tc==NULL in tuned_channel_nth_name().
  Not recently observed, perhaps fixed.
* Mute button is on after unmute, quit, restart. Seems to be a driver
  effect.
* bt8x8 has no PAL delay line, or is disabled in YUYV mode?
* tveng2/bttv-0.8.x permits capture size exceeding hardware capability?
* Audio mutes when switching from capture to fullscreen with
  bttv-0.8.x and Xv/v4l, although Zapping sends XvSetPortAttribute
  XV_MUTE 0. Works normal with bttv-0.7.
* Doesn't always reset hue on startup?
* drose: "Under mdk 9.1 the video capture stops for no reason.
  Start recording to a file -- come back in ten minutes, 1 - 3 minutes
  of video are stored and zapping wasn't running." Works for me.
* Overlay doesn't work right with RANDR reduced resolution, apparently
  due to wrong frame buffer bpl.
* bttv 0.9.14: with YUV 4:2:0 activation of VBI capturing can cause a
  SCERR & driver reset, DQBUF -> EIO.

Zapping 0.6 bugs, need verification:
* RPM creates incorrect zsfb.capps 
* zsfb.capps conflicts with RPM relocation.
* Look for endianness problems.
* vbi eats too much CPU, investigate.
* Overlay (no XVideo) under E is broken, shading the window
  isn't correctly detected.
* Do not assert on ESD timeout
* Bug in save window geometry, reported by Pawel.

tvengxv.c
* Need to handle BadAtom errors resulting from Xv out
  of video memory (or no v4l device?). Currently gdk traps errors
  and just aborts the App.
* We must not rely on XvQueryPortAttributes(), this is a later
  (XFree86-only?) extension of the XVideo API. It already defines
  some attribute names and ranges, and XvGetPortAttribute() will tell
  if they are implemented by the driver.
* configure.in must check for different versions of xv.

Debian
* 168263 - feature added in 0.7.
* 126641 - zapping_remote, see also sf.net. Without X to do.
* 170380 - rewrote in 0.7, user can override automatic selection.
* 169173 - rewrote in 0.7.
* 226590 - still in 0.6.8 (never notified - ??), rewrote in 0.7.
* 198942 - open.

XFree86 stuff
-------------

* XvQueryAdaptors seems to report wrong num_formats value, maybe a
  DIX or DDX bug.
* XvListImageFormats, XvQueryPortAttributes not documented. Result
  must be XFree()ed.
* XvImageFormat: Some drivers define incorrect component_order.
  There are no Window FOURCCs for RGB formats, consequently drivers
  disagree about id and guid.

V4L XVideo driver (xc/programs/Xserver/hw/xfree86/drivers/v4l/v4l.c)
* Success of ioctls is not checked.
* Does not consider audio.mode changes semantics on read/write.
  V4lSetPortAttribute():
    } else if (attribute == xvMute ||
	       attribute == xvVolume) {
	ioctl(V4L_FD,VIDIOCGAUDIO,&pPPriv->audio);
	if (attribute == xvMute) {
	    if (value)
		pPPriv->audio.flags |= VIDEO_AUDIO_MUTE;
	    else
		pPPriv->audio.flags &= ~VIDEO_AUDIO_MUTE;
	} else if (attribute == xvVolume) {
	    if (pPPriv->audio.flags & VIDEO_AUDIO_VOLUME)
		pPPriv->audio.volume = xv_to_v4l(value);
	} else {
	    ret = BadValue;
	}
	if (ret != BadValue)
	    if (-1 == ioctl(V4L_FD,VIDIOCSAUDIO,&pPPriv->audio))
		perror("ioctl VIDIOCSAUDIO");
* Encoding is not reset on open? Apparently cought when Zapping opens
  the v4l/2/5 interface too (try remove the modules in tveng.c, or
  start xv overlay while a radio app runs).
* Reports wrong tuner frequency range:
  static const XF86AttributeRec FreqAttr =
    {XvSettable | XvGettable,     0, 16*1000, XV_FREQ};
* Ignores tuner frequency scale factor (62.5 Hz, 62.5 kHz). Supposedly
  the Hz scale was added for SW radio, but the V4L/2 spec nowhere says
  tv receivers must support kHz only.
  V4lSetPortAttribute():
  } else if (attribute == xvFreq) {
      if (-1 == ioctl(V4L_FD,VIDIOCSFREQ,&value))
          perror("ioctl VIDIOCSFREQ");
  V4lGetPortAttribute():
  } else if (attribute == xvFreq) {
     ioctl(V4L_FD,VIDIOCGFREQ,value);
* XV_FREQ semantics not documented, e.g. scale 62.5 kHz.
* XvEncodingInfo does not report if the input is a tuner and
  XV_FREQ access appears to succeed on all inputs.
* According to XvQueryPortAttributes() this device has 2001
  video standards and inputs (no, I didn't try them :-)
  {XvSettable | XvGettable, -1000, 1000, XV_ENCODING}

NVidia driver (binary, not xf86)
* Reports tv output port with type XvInputMask | XvVideoMask.
  Should be XvOutputMask. Workaround in place.

NeoMagic driver (xc/programs/Xserver/hw/xfree86/drivers/neomagic)
* The only port is of type XvInputMask | XvImageMask | XvWindowMask |
  XvOutputMask | XvVideoMask. It supports PutVideo (video in) and
  PutImage (image out), probably not both at once. XvQueryAdaptors man
  page does not state if such a combination of flags has to be
  expected. Actually it doesn't even mention the XvImage extension.

Savage driver (xc/programs/Xserver/hw/xfree86/drivers/savage/savage_video.c)
* Minor nit: comment says YV12, I420 == 4:1:1, actually 4:2:0. The
  alleged 2:1:1 is really a half width 4:2:2, there's no such thing as 2:1:1.

Glint driver (xc/programs/Xserver/hw/xfree86/drivers/glint/pm2_video.c)
* Does not list XV_ENCODING with other attributes for
  XvQueryPortAttributes(). Only two other drivers have XV_ENCODING,
  namely V4L and SMI (xc/programs/Xserver/hw/xfree86/drivers/
  siliconmotion/smi_video.c), and both list it, but I wonder if it
  really belongs with attributes. This is no picture control and the
  info is redundant with XvQueryEncodings(). Workaround in place.

-------------------------------------------------------------------------------

If it ain't broke... it is now.
