On Sun, 11 Mar 2018 23:04:02 -0500
Nick French <n...@ou.edu> wrote:
> On Sun, Mar 11, 2018 at 11:24:38PM +0000, Ian Armstrong wrote:
> > On Sat, 10 Mar 2018 16:57:41 +
> > "French, Nicholas A." <n...@ou.edu> wrote:
> >
> > > >
On Sat, 10 Mar 2018 16:57:41 +
"French, Nicholas A." wrote:
> > > No what if the framebuffer driver is just requested as a
> > > secondary step after firmware loading?
> >
> > Its a possibility. The decoder firmware gets loaded at the
> > beginning of the decoder memory range
On Friday 20 April 2012, Ian Liverton wrote:
Thanks for this - I was in the middle of trying to sort this out when it
arrived! When I use it with dvbscan, however, it seems to mis-detect the
modulation on the SDN multiplex. It's telling me it's QPSK rather than
QAM_64. Did you have any
On Monday 07 November 2011, Hans Verkuil wrote:
During the recent V4L-DVB workshop we discussed the usage of the
V4L2_FBUF_FLAG_OVERLAY flag.
In the case of ivtv the behavior is as follows (from the original commit
message):
The existing yuv code limits output to the display area
On Sunday 23 May 2010, Hans Verkuil wrote:
On Saturday 22 May 2010 19:21:32 Ian Armstrong wrote:
On Saturday 22 May 2010, Andy Walls wrote:
Some thoughts:
1. to me it appears that the ivtv driver looks like it ties the output
standard to the input standard currently (probably due
On Saturday 22 May 2010, Andy Walls wrote:
On Sat, 2010-05-22 at 15:06 +0100, Andre Draszik wrote:
Hi,
As per the spec, the above ioctl codes are defined for inputs only -
it would be useful if there were similar codes for outputs.
I therefore propose to add the following:
On Friday 15 January 2010, Roel Kluin wrote:
vi drivers/media/video/ivtv/ivtv-yuv.c +971
and note that `args-dst.left' is assigned both to
nf-tru_x and nf-dst_x, is that ok?
It's fine. dst_x is used to set a hardware register and may be changed in
ivtv_yuv_window_setup()
tru_x is never