On Tuesday 24 November 2015 21:27:33 Jean-Michel Hautbois wrote:
> Hi,
> Le 24 nov. 2015 19:46, "Simon Farnsworth" a
> écrit :
> >
> > I was having trouble capturing raw video from GStreamer; turns out that I
> > now need VIDIOC_TRY_FMT to fill in
I was having trouble capturing raw video from GStreamer; turns out that I
now need VIDIOC_TRY_FMT to fill in sizeimage and bytesperline to make it work.
Signed-off-by: Simon Farnsworth
---
I'm leaving ONELAN on Friday, so this is a drive-by patch being sent for the
benefit of anyone else t
Current GStreamer userspace respects the bytes_per_line from the driver. Set
it to something reasonable for the format chosen.
Signed-off-by: Simon Farnsworth
---
I'm hoping this is trivially correct - I've only tested UYVY.
drivers/media/pci/cx18/cx18-driver.h | 1 +
drivers/medi
On Friday 31 October 2014 15:54:01 Hans Verkuil wrote:
> On 10/31/2014 03:48 PM, Simon Farnsworth wrote:
> > Documentation for enum v4l2_field did not make it clear that V4L2_FIELD_ANY
> > is only acceptable as input to the kernel, not as a response from the
> > driver.
>
Documentation for enum v4l2_field did not make it clear that V4L2_FIELD_ANY
is only acceptable as input to the kernel, not as a response from the
driver.
Make it clear, to stop userspace developers like me assuming it can be
returned by the driver.
Signed-off-by: Simon Farnsworth
---
Change
Documentation for enum v4l2_field did not make it clear that V4L2_FIELD_ANY
is only acceptable as input to the kernel, not as a response from the
driver.
Make it clear, to stop userspace developers like me assuming it can be
returned by the driver.
Signed-off-by: Simon Farnsworth
pm_qos_remove_request was not called on video_release, resulting in the PM
core's list of requests being corrupted when the file handle was freed.
This has no immediate symptoms, but later in operation, the kernel will
panic as the PM core dereferences a dangling pointer.
Signed-off-by:
ve
already outlined.
So, how do you provide such information? Is it enough to simply provide
strength in dBm, and quality as 0 to 100, where anything under 33 indicates
uncorrected errors, and anything under 66 indicates that quality is marginal?
--
Simon Farnsworth
Software Engineer
ONELAN Ltd
htt
r measure.
>
> As the wifi subsytem use dBm, I vote for using dBm for the signal measure
> at the subsystem (actually, 0.1 dBm).
>
0.1 dBm suits me. I just want something that I can present to the end user in
a format that will match their aerial installer's kit.
--
Simon
On Tuesday 8 January 2013 18:28:53 Devin Heitmueller wrote:
> On Tue, Jan 8, 2013 at 6:18 PM, Simon Farnsworth
> wrote:
> > The wireless folk use dBm (reference point 1 milliwatt), as that's the
> > reference point used in the 802.11 standard.
> >
> > Perhaps
On Tuesday 8 January 2013 19:00:11 Frank Schäfer wrote:
> Am 08.01.2013 12:45, schrieb Simon Farnsworth:
> > On Monday 7 January 2013 22:25:47 Mauro Carvalho Chehab wrote:
> >
> >> +
> >> +
> >> FE_SCALE_NOT_
ference against 1 microwatt, as (on the DVB-T and
ATSC cards I use) that leads to the signal measure being 0 dBµW if you've got
perfect signal, negative number if your signal is weak, and positive numbers
if your signal is strong. However, referenced against 1 milliwatt also works
well fo
seemingly random lines are
only partly transferred - if you feed in a static image, you see a portion
of the image "flicker" into place.
Signed-off-by: Simon Farnsworth
---
v2 changes: Reduced the latency further, based on a functional block level
datasheet. Comment updated to match.
As no
streaming, as I've seen buffer exhaustion. We've got far enough to know that
the value I chose was wrong for the saa7134, but Mauro also wants guidance on
whether USB devices (not host controllers) also need to request reduced
latency.
--
Simon Farnsworth
Software Engineer
ONELAN Ltd
htt
On Monday 29 October 2012 09:32:27 Andy Walls wrote:
> On Mon, 2012-10-29 at 13:02 +0000, Simon Farnsworth wrote:
> > It will affect other drivers as well; the basic cause is that modern chips
> > can enter a package deep sleep state that affects both CPU speed and latency
> >
h it. I suspect that most old drivers will need
updating if anyone wants to use them with modern systems; either they'll have
an architecture like the cx18 series, and the type of work Andy has done will
fix the problem, or they'll behave like the saa7134, and need a pm_qos request
to ensure t
On Monday 22 October 2012 12:50:11 Simon Farnsworth wrote:
> The SAA7134 appears to have trouble buffering more than one line of video
> when doing DMA. Rather than try to fix the driver to cope (as has been done
> by Andy Walls for the cx18 driver), put in a pm_qos_request to limit dee
seemingly random lines are
only partly transferred - if you feed in a static image, you see a portion
of the image "flicker" into place.
Signed-off-by: Simon Farnsworth
---
As per the comment, note that I've not been able to nail down the maximum
latency the SAA7134 can cope with. I kno
On Friday 19 October 2012 17:10:17 Simon Farnsworth wrote:
> Mauro, Linux-Media
>
> I have an issue where an SAA7134-based TV capture card connected via a PCIe to
> PCI bridge chip works when the GPU is kept out of RC6 state, but sometimes
> "skips" updating lines of th
t; If you have one of the latest HVR1600's with that analog tuner, does PAL-D
> work with it without and offset?
>
I don't have a current model HVR-1600 to hand - if I get hold of one, I will
test it.
--
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.com/
On Friday 30 September 2011, Malcolm Priestley wrote:
> On 28/09/11 13:50, Simon Farnsworth wrote:
> > (note - the CC list is everyone over 50% certainty from get_maintainer.pl)
> >
> > I'm having problems getting a Hauppauge HVR-1110 card to successfully
> >
On Friday 30 September 2011, Mauro Carvalho Chehab
wrote:
> Em 28-09-2011 09:50, Simon Farnsworth escreveu:
> > (note - the CC list is everyone over 50% certainty from get_maintainer.pl)
> >
> > I'm having problems getting a Hauppauge HVR-1110 card to successfully
&g
On Friday 30 September 2011, Mauro Carvalho Chehab
wrote:
> Em 28-09-2011 09:50, Simon Farnsworth escreveu:
> > (note - the CC list is everyone over 50% certainty from get_maintainer.pl)
> >
> > I'm having problems getting a Hauppauge HVR-1110 card to successfully
&g
On Wednesday 28 September 2011, Devin Heitmueller
wrote:
> Hi Simon,
>
> On Wed, Sep 28, 2011 at 8:50 AM, Simon Farnsworth
>
> wrote:
> >
> > I'm having problems getting a Hauppauge HVR-1110 card to successfully
> > tune PAL-D at 85.250 MHz visi
eband going down to 84.5 MHz, and the other
going up to 90.5MHz. I also see an audio carrier at 91.75 MHz.
I'm going to run with this hack in place, but I'd appreciate it if
someone who knew more about the TDA18271 looked at this, and either
gave me a proper fix for testing, or confirmed
ad of HM12, while our GStreamer code was picking HM12 in
some circumstances.
Finally, the V4L2_CAP_STREAMING capability was never exposed. Patch it
into the YUV encoder node only.
Signed-off-by: Simon Farnsworth
---
This patch, against linuxtv/staging/for_v3.2, makes the upstream code
for videobuf
The initialisation of vb_type in serialized_open was preventing
REQBUFS from working reliably. Remove it, and move the spinlock into
stream_init for good measure - it's only used when we have a stream
that supports videobuf anyway.
Signed-off-by: Simon Farnsworth
---
Mauro,
This fixes a
On Thursday 5 May 2011, Mauro Carvalho Chehab wrote:
> Em 05-05-2011 09:42, Simon Farnsworth escreveu:
> > I misused the ktime API, and failed to remove some traces of the
> > in-kernel format conversion. Fix these, so the the driver builds
> > without warnings.
> >
s
elsewhere in this thread (in reply to <4dc138f7.5050...@infradead.org>)
--
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
I misused the ktime API, and failed to remove some traces of the
in-kernel format conversion. Fix these, so the the driver builds
without warnings.
Signed-off-by: Simon Farnsworth
---
Mauro,
You may want to squash this in with the cleanup patch itself - it's
plain and simple oversight
To simplify maintainer support of this driver, bump the version to
1.5.0 - this will be the first version that is expected to support
mmap() for raw video frames.
Signed-off-by: Simon Farnsworth
---
Mauro,
This is an incremental patch to apply on top of my cleanup patch - if
you would prefer a
wo patches, would you mind bumping the
version in cx18-version.c for me as you apply them, or would you prefer me to
provide either an incremental patch or a new patch with the bump added?
--
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.com/
--
To unsubscribe from this list:
ugh free time to convert the existing
patch for me, I can free up enough time to test with our application and with
GStreamer, to confirm that the conversion works adequately.
--
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.com/
--
To unsubscribe from this list: sen
ideobuf to videobuf2
to do.
Signed-off-by: Simon Farnsworth
---
drivers/media/video/cx18/Kconfig|1 -
drivers/media/video/cx18/cx18-driver.h |8 +-
drivers/media/video/cx18/cx18-fileops.c | 167 +++
drivers/media/video/cx18/cx18-ioctl.
4l here anyway, so it's not needed)
I have one more work item, requested by Andy and Hans, and that's to convert
just the YUV capture from videobuf to vb2, so that when Andy's got spare time
again, it'll be easier for him to convert the whole driver. I've been delayed
on t
ginal code is at
http://www.kernellabs.com/hg/~stoth/cx18-videobuf
Signed-off-by: Simon Farnsworth
---
I'm currently running an older version of this patch on a 2.6.37
kernel - I figured I should try and get this into mainline sooner
rather than later, given the current rate of change in V
echanism called
request_firmware() that does what you want; it's used in several V4L
drivers if you need an example usage.
--
Simon Farnsworth
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majo
p. I have the
> MXL5005S showing up at 9.510:
>
> [9.510767] MXL5005S: Attached at address 0x63
So basically, I was being blind and/or stupid - with this to hand, I've
found the equivalent message in my dmesg.
--
Simon Farnsworth
--
To unsubscribe from this list: send the line "
standing dmesg here? I see references to a Samsung S5H1409,
not to an mxl5005s; if I've read the driver code correctly, I'd see a
KERN_INFO printk for the mxl5005s when it comes up.
--
Simon Farnsworth
--
To unsubscribe from this list: send the line "unsubscribe linux-media"
12500:QAM_256:0:0:5
Any ideas?
--
I can do any further investigation or experiments required,
Simon Farnsworth
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 2.6.30-1.NTB5.fc8.i686.PAE
(sfarnswo...@f8simon.office.onelan.co.uk) (gcc version 4.1.2 20070925 (Red Hat
Hello Andy,
Just a brief note to let you know that ALSA support in cx18 is near the
top of my priorities now. I'm going to start with your work at
http://linuxtv.org/hg/~awalls/mc-lab
--
I'll send patches as and when I get things working,
Simon Farnsworth
--
To unsubscribe from
Andy Walls wrote:
> On Thu, 2009-09-03 at 12:23 +0100, Simon Farnsworth wrote:
>> Andy Walls wrote:
>>> But I suspect no user pays for the extra cost of the CX2341[568]
>>> hardware MPEG encoder, if the user primarily wants uncompressed YUV
>>> video as their m
s uncompressed YUV and ATSC (both OTA and
ClearQAM cable). As we already buy Hauppauge HVR-1110s for DVB-T and
uncompressed analogue, a Hauppauge card suits us, and the only thing
they have that fits the needs is the HVR-1600; the MPEG encoder is thus
left idle.
--
Simon Farnsworth
--
To unsubsc
ct this case, and how should I
configure the PCM audio device?
If the driver needs modifying, I can do this, but I'll need an
explanation of how to do so without breaking things for other people -
I've not done much with ALSA drivers or with V4L2 drivers.
--
Simon Farnsworth
--
To u
Simon Farnsworth wrote:
> I appear to lose colour after a few seconds of capture, which I shall chase
> further.
And resolved - I was off-frequency by 2MHz, which leaves me surprised that
I got picture. Only thing left for me to sort out is audio support.
--
Thanks for your help,
Simon Farnsworth wrote:
> Hans de Goede wrote:
>> Ok,
>>
>> That was even easier then I thought it would be. Attached is a
>> patch (against libv4l-0.6.1), which implements 1) and 3) from
>> above.
>>
> I applied it to a clone of your HG repository, and
try and chase this, see whether
there's something obviously wrong.
The repository I went against was http://linuxtv.org/hg/~hgoede/libv4l/
identified as:
$ hg identify
c51a90c0f62f+ tip
--
Simon Farnsworth
diff -r c51a90c0f62f v4l2-apps/libv4l/libv4l2/libv4l2.c
--- a/v4l2-apps/libv4l/libv
Hans de Goede wrote:
> Hi,
>
> On 09/02/2009 06:32 PM, Simon Farnsworth wrote:
>> I have a Hauppauge HVR1600 for NTSC and ATSC support, and it appears to
>> simply not work with libv4l2, due to lack of mmap support. My code works
>> adequately (modulo a nice pile of bu
use mmap?
If it's a case of converting the cx18 driver, how would I go about doing
that? I have no experience of the driver, so I'm not sure what I'd have
to do - noting that if I break the existing read() support, other users
will get upset.
--
Advice appreciated,
Simon Farnswort
49 matches
Mail list logo
