On Sun, 11 Mar 2018 23:04:02 -0500
Nick French 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." wrote:
> >
> > > > > No what if the framebuffer driver is just
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 and we know it
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 ar
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
> >
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 followin
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 nev
