Bug 116217

Description of problem:
xawtv is slow to display an image, taking 7 seconds from
command issue to appearance of the first image

Version-Release number of selected component (if applicable):
xawtv-3.81-6

How reproducible:
100%

Steps to Reproduce:
1. Use DISPLAY 2:0 (modified startx script, per
encouragement in the supplied startx script)

2. Issue the 'xawtv' command.

3.
  
Actual results:
xawtv puts up a black window immediately.  However,
it is 7 seconds from command issue before the real
image appears in the window

Expected results:
xawtv should display the real image promptly, as
RHL 7.2 for Alpha and RHL 8.0 for X86 did.

Additional info:
Based on the output of strace, it appears xawtv is
attempting to access /tmp/.X11-unix-X0 in a loop
with 1-second nanosleep calls, even though it has
earlier properly accessed /tmp/.X11-unix-X2.

My /etc/hosts file uses static IP addresses for the
nodes on my home network (behind NAT/firewall box).
I have tried both 'one' and 'one.localnet' as 127.0.0.1
and as 192.168.254.101, with no difference in results.
I'm runing the caching nameserver but no other DNS
services.  I'm not running NIS.

I have had to make v4l-conf suid root, because I use
runlevel 3 and release the text virtual console after
starting the X server, so the console.apps stuff is not
useful.  None of that changed between RHL 8.0 and RHL 9.

I'm using a Radeon 7500 AGP graphics card on an Iwill
P4ES motherboard, Intel 845E chipset, 1600x1200 resolution
at 24/32 bit color depth, mwm window manager.  My .Xdefaults
file sets Mwm*xawtv.clientDecoration: none,
xawtv*geometry: 384x288-0-0.  My .xawtv file selects
us-bcst carriers, NTSC, Composite1 input. My BTTV card
is a WinTV Series by Hauppauge, Bt878 chip.

Essentially none of the setup changed between RHL 8.0
and RHL 9.  I never saw the slowness/delay with RHL 8.0,
and I always see it with RHL 9.  All other X applications
come up promptly _except_ xlock (compiled into
/usr/local from an older .src.rpm), which always has the
same ~7 second delay before taking over the display.  It
also never showed delay with RHL 8.0 and always shows it
with RHL 9.

Someone on a newsgroup suggested trying the bit_test=1
option for module i2c-algo-bit.  That did not help, but
it showed the I2C bus test as passing.

One hypothesis is an X authentication issue.  Another is
a DNS lookup and timeout issue.  However, I'm inclined to
suspect one of the X libraries is mistakenly assuming
display is :0.0 instead of getting it right.  I'll try to
attach the output of strace.