Urgently need money? We can help you!

[Mr. Muller Dieter]

Urgently need money? We can help you!
Are you by the current situation in trouble or threatens you in trouble?
In this way, we give you the ability to take a new development.
As a rich person I feel obliged to assist people who are struggling to give 
them a chance. Everyone deserved a second chance and since the Government 
fails, it will have to come from others.
No amount is too crazy for us and the maturity we determine by mutual agreement.
No surprises, no extra costs, but just the agreed amounts and nothing else.
Don't wait any longer and comment on this post. Please specify the amount you 
want to borrow and we will contact you with all the possibilities. contact us 
today at stewarrt.l...@gmail.com

I NEED YOUR HELP URGENTLY!!!

[GEN KELVIN]

Compliment of the day to you. I am Gen.Kelvin W Howard, I am sending this brief 
letter to solicit your partnership of Sixteen  Million Two Hundred Thousand 
United States Dollars ($16,200,000). I shall send you more information and 
procedures when I receive positive response from you.Best Regards,
CONTACT ME: kivenhow...@gmail.com
Gen.Kelvin W Howard

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Help me for investment

[Aisha Gaddafi]

--
Dear Assalamu Alaikum,
I came across your contact during my private search
Mrs Aisha Al-Qaddafi is my name, the only daughter of late Libyan
president, I have funds the sum
of $27.5 million USD for investment, I am interested in you for
investment project assistance in your country,
i shall compensate you 30% of the total sum after the funds are
transfer into your account,
Greetings from Mrs Aisha Al-Qaddafi
Mrs Aisha Al-Qaddafi
--

Dear Friend i need your help

[Aisha Gaddafi]

--
Dear Assalamu Alaikum,
I came across your contact during my private search
Mrs Aisha Al-Qaddafi is my name, the only daughter of late Libyan
president, I have funds the sum
of $27.5 million USD for investment, I am interested in you for
investment project assistance in your country,
i shall compensate you 30% of the total sum after the funds are
transfer into your account,
Greetings from Mrs Aisha Al-Qaddafi
Mrs Aisha Al-Qaddafi
--

help

[Richard Lee]

[Solved] Help needed for zolid usb dvb-t stick

[mjs]

Solved.
See msg130325.

Thanks,
  Marcel

[PATCH] media: gspca: fix Kconfig help info

[winton.liu]

Documentation/video4linux/gspca.txt is missing.
It has moved to Documentation/media/v4l-drivers/gspca-cardlist.rst

Signed-off-by: winton.liu <18502523...@163.com>
---
 drivers/media/usb/gspca/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/gspca/Kconfig b/drivers/media/usb/gspca/Kconfig
index d214a21..bc9a439 100644
--- a/drivers/media/usb/gspca/Kconfig
+++ b/drivers/media/usb/gspca/Kconfig
@@ -7,7 +7,7 @@ menuconfig USB_GSPCA
  Say Y here if you want to enable selecting webcams based
  on the GSPCA framework.
 
- See  for more info.
+ See  for 
more info.
 
  This driver uses the Video For Linux API. You must say Y or M to
  "Video For Linux" to use this driver.
-- 
2.7.4

help needed: dvb-usb: recv bulk message failed: -110 AND dw2102: i2c transfer failed

[rwar...@gmx.de]

Hallo

I get this with kernel 4.15.8 and 4.16-rc5

...
[ 166.277588] dvb-usb: Terratec Cinergy S2 USB BOX successfully 
deinitialized and disconnected.


[ 168.406828] usb 1-1: new high-speed USB device number 6 using xhci_hcd

[ 168.534421] dw2102: su3000_identify_state

[ 168.534424] dvb-usb: found a 'Terratec Cinergy S2 USB BOX' in warm state.

[ 168.534433] dw2102: su3000_power_ctrl: 1, initialized 0

[ 168.534642] dvb-usb: will pass the complete MPEG2 transport stream to 
the software demuxer.


[ 168.534708] dvbdev: DVB: registering new adapter (Terratec Cinergy S2 
USB BOX)


[ 168.538862] dvb-usb: MAC address: bc:ea:2b:46:13:a5

[ 168.849764] m88ds3103 5-0068: Unknown device. Chip_id=52

[ 168.849816] dvb-usb: no frontend was attached by 'Terratec Cinergy S2 
USB BOX'


[ 168.849945] Registered IR keymap rc-tt-1500

[ 168.850002] rc rc0: Terratec Cinergy S2 USB BOX as 
/devices/pci:00/:00:14.0/usb1/1-1/rc/rc0


[ 168.850084] input: Terratec Cinergy S2 USB BOX as 
/devices/pci:00/:00:14.0/usb1/1-1/rc/rc0/input20


[ 168.850287] dvb-usb: schedule remote query interval to 250 msecs.

[ 168.850291] dw2102: su3000_power_ctrl: 0, initialized 1

[ 168.850293] dvb-usb: Terratec Cinergy S2 USB BOX successfully 
initialized and connected.


[ 171.141939] dvb-usb: recv bulk message failed: -110

[ 171.141949] dw2102: i2c transfer failed.


more to read:
https://forum.libreelec.tv/thread/11784-does-this-dvb-s2-tuner-work/?pageNo=4

--

Greeting

Ronald

Trying to build V4L on an Orange Pi One Plus - Build failed - Help wanted

[Aurelius Wendelken]

xfj linux-media.tar.bz2
rm -f .patches_applied .linked_dir .git_log.md5
make: Leaving directory '/root/git/media_build/linux'
**
* Downloading firmwares from linuxtv.org.    *
**
as102_data1_st.hex
as102_data2_st.hex
cmmb_vega_12mhz.inp
cmmb_venice_12mhz.inp
dvb-fe-bcm3510-01.fw
dvb-fe-drxj-mc-1.0.8.fw
dvb-fe-drxj-mc-vsb-1.0.8.fw
dvb-fe-drxj-mc-vsb-qam-1.0.8.fw
dvb-fe-or51132-qam.fw
dvb-fe-or51132-vsb.fw
dvb-fe-or51211.fw
dvb-fe-xc4000-1.4.1.fw
dvb-fe-xc5000-1.6.114.fw
dvb-fe-xc5000c-4.1.30.7.fw
dvb-firmwares.tar.bz2
dvb-ttpci-01.fw-261a
dvb-ttpci-01.fw-261b
dvb-ttpci-01.fw-261c
dvb-ttpci-01.fw-261d
dvb-ttpci-01.fw-261f
dvb-ttpci-01.fw-2622
dvb-usb-avertv-a800-02.fw
dvb-usb-bluebird-01.fw
dvb-usb-dib0700-1.20.fw
dvb-usb-dibusb-5.0.0.11.fw
dvb-usb-dibusb-6.0.0.8.fw
dvb-usb-dtt200u-01.fw
dvb-usb-it9135-01.fw
dvb-usb-it9135-02.fw
dvb-usb-terratec-h5-drxk.fw
dvb-usb-terratec-h7-az6007.fw
dvb-usb-terratec-h7-drxk.fw
dvb-usb-umt-010-02.fw
dvb-usb-vp702x-01.fw
dvb-usb-vp7045-01.fw
dvb-usb-wt220u-01.fw
dvb-usb-wt220u-02.fw
dvb_nova_12mhz.inp
dvb_nova_12mhz_b0.inp
isdbt_nova_12mhz.inp
isdbt_nova_12mhz_b0.inp
isdbt_rio.inp
sms1xxx-hcw-55xxx-dvbt-02.fw
sms1xxx-hcw-55xxx-isdbt-02.fw
sms1xxx-nova-a-dvbt-01.fw
sms1xxx-nova-b-dvbt-01.fw
sms1xxx-stellar-dvbt-01.fw
tdmb_nova_12mhz.inp
v4l-cx231xx-avcore-01.fw
v4l-cx23418-apu.fw
v4l-cx23418-cpu.fw
v4l-cx23418-dig.fw
v4l-cx23885-avcore-01.fw
v4l-cx23885-enc-broken.fw
v4l-cx25840.fw
**
* Start building *
**
make -C /root/git/media_build/v4l allyesconfig
make[1]: Entering directory '/root/git/media_build/v4l'
make[2]: Entering directory '/root/git/media_build/linux'
Applying patches for kernel 3.10.65
patch -s -f -N -p1 -i ../backports/api_version.patch
patch -s -f -N -p1 -i ../backports/pr_fmt.patch
patch -s -f -N -p1 -i ../backports/debug.patch
patch -s -f -N -p1 -i ../backports/drx39xxj.patch
patch -s -f -N -p1 -i ../backports/v4.14_compiler_h.patch
patch -s -f -N -p1 -i ../backports/v4.14_saa7146_timer_cast.patch
patch -s -f -N -p1 -i ../backports/v4.14_module_param_call.patch
patch -s -f -N -p1 -i 
../backports/v4.12_revert_solo6x10_copykerneluser.patch

patch -s -f -N -p1 -i ../backports/v4.10_sched_signal.patch
patch -s -f -N -p1 -i ../backports/v4.10_fault_page.patch
patch -s -f -N -p1 -i ../backports/v4.10_refcount.patch
patch -s -f -N -p1 -i ../backports/v4.9_mm_address.patch
patch -s -f -N -p1 -i ../backports/v4.9_dvb_net_max_mtu.patch
patch -s -f -N -p1 -i ../backports/v4.9_ktime_cleanups.patch
patch -s -f -N -p1 -i ../backports/v4.9_uvcvideo_ktime_conversion.patch
patch -s -f -N -p1 -i ../backports/v4.8_user_pages_flag.patch
patch -s -f -N -p1 -i ../backports/v4.7_dma_attrs.patch
patch -s -f -N -p1 -i ../backports/v4.7_pci_alloc_irq_vectors.patch
patch -s -f -N -p1 -i ../backports/v4.6_i2c_mux.patch
patch -s -f -N -p1 -i ../backports/v4.5_gpiochip_data_pointer.patch
patch -s -f -N -p1 -i ../backports/v4.5_get_user_pages.patch
patch -s -f -N -p1 -i ../backports/v4.5_uvc_super_plus.patch
patch -s -f -N -p1 -i ../backports/v4.4_gpio_chip_parent.patch
patch -s -f -N -p1 -i ../backports/v4.3_add_autorepeat_handling.patch
patch -s -f -N -p1 -i ../backports/v4.2_atomic64.patch
patch -s -f -N -p1 -i ../backports/v4.2_frame_vector.patch
patch -s -f -N -p1 -i ../backports/v4.1_pat_enabled.patch
patch -s -f -N -p1 -i ../backports/v4.1_drop_fwnode.patch
patch -s -f -N -p1 -i ../backports/v4.0_dma_buf_export.patch
patch -s -f -N -p1 -i ../backports/v4.0_drop_trace.patch
patch -s -f -N -p1 -i ../backports/v4.0_fwnode.patch
patch -s -f -N -p1 -i ../backports/v3.19_get_user_pages_unlocked.patch
patch -s -f -N -p1 -i ../backports/v3.19_get_user_pages_locked.patch
patch -s -f -N -p1 -i ../backports/v3.18_drop_property_h.patch
patch -s -f -N -p1 -i ../backports/v3.18_ktime_get_real_seconds.patch
patch -s -f -N -p1 -i ../backports/v3.17_fix_clamp.patch
patch -s -f -N -p1 -i ../backports/v3.16_netdev.patch
patch -s -f -N -p1 -i ../backports/v3.16_wait_on_bit.patch
patch -s -f -N -p1 -i ../backports/v3.16_void_gpiochip_remove.patch
patch -s -f -N -p1 -i ../backports/v3.13_ddbridge_pcimsi.patch
patch -s -f -N -p1 -i ../backports/v3.12_kfifo_in.patch
2 out of 3 hunks FAILED
Makefile:130: recipe for target 'apply_patches' failed
make[2]: *** [apply_patches] Error 1
make[2]: Leaving directory '/root/git/media_build/linux'
Makefile:374: recipe for target 'allyesconfig' failed
make[1]: *** [allyesconfig] Error 2
make[1]: Leaving directory '/root/git/media_build/v4l'
Makefile:26: recipe for target 'allyesconfig' failed
make: *** [allyesconfig] Error 2
can't select all drivers at ./build line 525



Any help is appreciated,

Regards
Aurelius

Re: Please help test the new v4l-subdev support in v4l2-compliance

[Tim Harvey]

On Tue, Feb 6, 2018 at 11:05 AM, Hans Verkuil  wrote:
> On 02/06/2018 07:48 PM, Tim Harvey wrote:
>> On Mon, Feb 5, 2018 at 11:34 PM, Hans Verkuil  wrote:
>>> On 02/06/2018 08:16 AM, Tim Harvey wrote:
 On Sat, Feb 3, 2018 at 7:56 AM, Hans Verkuil  wrote:
>> 

 With regards to the 3 failures:

 1. test VIDIOC_G/S_EDID: FAIL
 This is a valid catch where I was returning -EINVAL when the caller
 was simply querying the edid - I've fixed it in my driver

 2. test VIDIOC_DV_TIMINGS_CAP: FAIL
 fail: v4l2-test-io-config.cpp(375): doioctl(node,
 VIDIOC_DV_TIMINGS_CAP, ) != EINVAL
 fail: v4l2-test-io-config.cpp(392): EDID check failed for source pad 0.

 It looks like the purpose of the test is to do an ioctl with an
 invalid pad setting to ensure -EINVAL is returned. However by the time
 the VIDIOC_DV_TIMINGS_CAP ioctl used here gets routed to a
>>>
>>> No, VIDIOC_SUBDEV_DV_TIMINGS_CAP == VIDIOC_DV_TIMINGS_CAP, i.e. the
>>> v4l-subdev API reuses the same ioctl as is used in the 'main' V4L2 API.
>>> See include/uapi/linux/v4l2-subdev.h at the end for a list of 'alias'
>>> ioctls.
>>
>> Ah... thanks - I realized that was happening somehow but couldn't see how :)
>>
>>>
>>> Looking at v7 your tda1997x_get_dv_timings_cap() function doesn't check
>>> for a valid pad field. Same for tda1997x_enum_dv_timings().
>>
>> Right - I noticed this right off as well - I've added pad validation
>> but that didn't resolve the failure.
>>
>> The test failing is:
>>
>> memset(, 0, sizeof(timingscap));
>> timingscap.pad = node->is_subdev() ? node->entity.pads : 1;
>>  this sets pad=node->entity.pads=1 which is invalid
>> fail_on_test(doioctl(node, VIDIOC_DV_TIMINGS_CAP, )
>> != EINVAL);
>>  tda1997x_get_dv_timings_cap() gets called with cap->pad = 0 which
>> is valid to returns 0. I don't understand how the userspace pad=1 get
>> changed to pad=0 in my handler.
>
> Actually, you don't need to test the pad in the driver, I just looked at
> the code in v4l2-core/v4l2-subdev.c and the pad is tested there already.
>
> And I just found why it is cleared: it's a bug in v4l2-ioctl.c.
>
> Look up VIDIOC_DV_TIMINGS_CAP in the big table and change this:
>
> INFO_FL_CLEAR(v4l2_dv_timings_cap, type)
>
> to this:
>
> INFO_FL_CLEAR(v4l2_dv_timings_cap, pad)
>
> We never noticed this because we never tested this for subdevs. And that's
> why you write compliance tests!

Indeed that fixes it. I'll add that patch to my series.

All of the items on your review of v7 make sense and I'll be posting a
v8 hopefully shortly.

Thanks!

Tim

Re: Please help test the new v4l-subdev support in v4l2-compliance

[Hans Verkuil]

On 02/06/2018 07:48 PM, Tim Harvey wrote:
> On Mon, Feb 5, 2018 at 11:34 PM, Hans Verkuil  wrote:
>> On 02/06/2018 08:16 AM, Tim Harvey wrote:
>>> On Sat, Feb 3, 2018 at 7:56 AM, Hans Verkuil  wrote:
> 
>>>
>>> With regards to the 3 failures:
>>>
>>> 1. test VIDIOC_G/S_EDID: FAIL
>>> This is a valid catch where I was returning -EINVAL when the caller
>>> was simply querying the edid - I've fixed it in my driver
>>>
>>> 2. test VIDIOC_DV_TIMINGS_CAP: FAIL
>>> fail: v4l2-test-io-config.cpp(375): doioctl(node,
>>> VIDIOC_DV_TIMINGS_CAP, ) != EINVAL
>>> fail: v4l2-test-io-config.cpp(392): EDID check failed for source pad 0.
>>>
>>> It looks like the purpose of the test is to do an ioctl with an
>>> invalid pad setting to ensure -EINVAL is returned. However by the time
>>> the VIDIOC_DV_TIMINGS_CAP ioctl used here gets routed to a
>>
>> No, VIDIOC_SUBDEV_DV_TIMINGS_CAP == VIDIOC_DV_TIMINGS_CAP, i.e. the
>> v4l-subdev API reuses the same ioctl as is used in the 'main' V4L2 API.
>> See include/uapi/linux/v4l2-subdev.h at the end for a list of 'alias'
>> ioctls.
> 
> Ah... thanks - I realized that was happening somehow but couldn't see how :)
> 
>>
>> Looking at v7 your tda1997x_get_dv_timings_cap() function doesn't check
>> for a valid pad field. Same for tda1997x_enum_dv_timings().
> 
> Right - I noticed this right off as well - I've added pad validation
> but that didn't resolve the failure.
> 
> The test failing is:
> 
> memset(, 0, sizeof(timingscap));
> timingscap.pad = node->is_subdev() ? node->entity.pads : 1;
>  this sets pad=node->entity.pads=1 which is invalid
> fail_on_test(doioctl(node, VIDIOC_DV_TIMINGS_CAP, )
> != EINVAL);
>  tda1997x_get_dv_timings_cap() gets called with cap->pad = 0 which
> is valid to returns 0. I don't understand how the userspace pad=1 get
> changed to pad=0 in my handler.

Actually, you don't need to test the pad in the driver, I just looked at
the code in v4l2-core/v4l2-subdev.c and the pad is tested there already.

And I just found why it is cleared: it's a bug in v4l2-ioctl.c.

Look up VIDIOC_DV_TIMINGS_CAP in the big table and change this:

INFO_FL_CLEAR(v4l2_dv_timings_cap, type)

to this:

INFO_FL_CLEAR(v4l2_dv_timings_cap, pad)

We never noticed this because we never tested this for subdevs. And that's
why you write compliance tests!

> 
>>
>>> VIDIOC_SUBDEV_DV_TIMINGS_CAP the pad is changed to 0 which is valid.
>>> I'm not following what's going on here.
>>>
>>> 3. test Try VIDIOC_SUBDEV_G/S_FMT: FAIL
>>> fail: v4l2-test-subdevs.cpp(303): fmt.code == 0 || fmt.code == ~0U
>>> fail: v4l2-test-subdevs.cpp(342): checkMBusFrameFmt(node, fmt.format)
>>>
>>> This is reporting that a VIDIOC_SUBDEV_G_FMT with
>>> which=V4L2_SUBDEV_FORMAT_TRY returns format->code = 0. The following
>>> is my set_format:
>>>
>>> static int tda1997x_get_format(struct v4l2_subdev *sd,
>>>struct v4l2_subdev_pad_config *cfg,
>>>struct v4l2_subdev_format *format)
>>> {
>>> struct tda1997x_state *state = to_state(sd);
>>>
>>> v4l_dbg(1, debug, state->client, "%s pad=%d which=%d\n",
>>> __func__, format->pad, format->which);
>>> if (format->pad != TDA1997X_PAD_SOURCE)
>>> return -EINVAL;
>>>
>>> tda1997x_fill_format(state, >format);
>>>
>>> if (format->which == V4L2_SUBDEV_FORMAT_TRY) {
>>> struct v4l2_mbus_framefmt *fmt;
>>>
>>> fmt = v4l2_subdev_get_try_format(sd, cfg, format->pad);
>>> format->format.code = fmt->code;
>>> } else {
>>> format->format.code = state->mbus_code;
>>> }
>>>
>>> return 0;
>>> }
>>>
>>> I don't at all understand the V4L2_SUBDEV_FORMAT_TRY logic here which
>>> I took from other subdev drivers as boilerplate. Is the test valid?
>>
>> The test is valid, this really shouldn't return a 0 code. But I am not
>> sure what the right logic is. I'll need to do some digging myself.
> 
> I got lost in the v4l2_subdev_get_try_format implementation but closer
> inspection shows me that v4l2_subdev_get_try_format returns the
> try_fmt field of the v4l2_subdev_pad_config used for storing subdev
> pad info. What I'm missing is how that struct/field gets initialized?
> Do I need to implement an init_cfg op?

See my review of v7.

Regards,

Hans

Re: Please help test the new v4l-subdev support in v4l2-compliance

[Tim Harvey]

On Mon, Feb 5, 2018 at 11:34 PM, Hans Verkuil  wrote:
> On 02/06/2018 08:16 AM, Tim Harvey wrote:
>> On Sat, Feb 3, 2018 at 7:56 AM, Hans Verkuil  wrote:

>>
>> With regards to the 3 failures:
>>
>> 1. test VIDIOC_G/S_EDID: FAIL
>> This is a valid catch where I was returning -EINVAL when the caller
>> was simply querying the edid - I've fixed it in my driver
>>
>> 2. test VIDIOC_DV_TIMINGS_CAP: FAIL
>> fail: v4l2-test-io-config.cpp(375): doioctl(node,
>> VIDIOC_DV_TIMINGS_CAP, ) != EINVAL
>> fail: v4l2-test-io-config.cpp(392): EDID check failed for source pad 0.
>>
>> It looks like the purpose of the test is to do an ioctl with an
>> invalid pad setting to ensure -EINVAL is returned. However by the time
>> the VIDIOC_DV_TIMINGS_CAP ioctl used here gets routed to a
>
> No, VIDIOC_SUBDEV_DV_TIMINGS_CAP == VIDIOC_DV_TIMINGS_CAP, i.e. the
> v4l-subdev API reuses the same ioctl as is used in the 'main' V4L2 API.
> See include/uapi/linux/v4l2-subdev.h at the end for a list of 'alias'
> ioctls.

Ah... thanks - I realized that was happening somehow but couldn't see how :)

>
> Looking at v7 your tda1997x_get_dv_timings_cap() function doesn't check
> for a valid pad field. Same for tda1997x_enum_dv_timings().

Right - I noticed this right off as well - I've added pad validation
but that didn't resolve the failure.

The test failing is:

memset(, 0, sizeof(timingscap));
timingscap.pad = node->is_subdev() ? node->entity.pads : 1;
 this sets pad=node->entity.pads=1 which is invalid
fail_on_test(doioctl(node, VIDIOC_DV_TIMINGS_CAP, )
!= EINVAL);
 tda1997x_get_dv_timings_cap() gets called with cap->pad = 0 which
is valid to returns 0. I don't understand how the userspace pad=1 get
changed to pad=0 in my handler.

>
>> VIDIOC_SUBDEV_DV_TIMINGS_CAP the pad is changed to 0 which is valid.
>> I'm not following what's going on here.
>>
>> 3. test Try VIDIOC_SUBDEV_G/S_FMT: FAIL
>> fail: v4l2-test-subdevs.cpp(303): fmt.code == 0 || fmt.code == ~0U
>> fail: v4l2-test-subdevs.cpp(342): checkMBusFrameFmt(node, fmt.format)
>>
>> This is reporting that a VIDIOC_SUBDEV_G_FMT with
>> which=V4L2_SUBDEV_FORMAT_TRY returns format->code = 0. The following
>> is my set_format:
>>
>> static int tda1997x_get_format(struct v4l2_subdev *sd,
>>struct v4l2_subdev_pad_config *cfg,
>>struct v4l2_subdev_format *format)
>> {
>> struct tda1997x_state *state = to_state(sd);
>>
>> v4l_dbg(1, debug, state->client, "%s pad=%d which=%d\n",
>> __func__, format->pad, format->which);
>> if (format->pad != TDA1997X_PAD_SOURCE)
>> return -EINVAL;
>>
>> tda1997x_fill_format(state, >format);
>>
>> if (format->which == V4L2_SUBDEV_FORMAT_TRY) {
>> struct v4l2_mbus_framefmt *fmt;
>>
>> fmt = v4l2_subdev_get_try_format(sd, cfg, format->pad);
>> format->format.code = fmt->code;
>> } else {
>> format->format.code = state->mbus_code;
>> }
>>
>> return 0;
>> }
>>
>> I don't at all understand the V4L2_SUBDEV_FORMAT_TRY logic here which
>> I took from other subdev drivers as boilerplate. Is the test valid?
>
> The test is valid, this really shouldn't return a 0 code. But I am not
> sure what the right logic is. I'll need to do some digging myself.

I got lost in the v4l2_subdev_get_try_format implementation but closer
inspection shows me that v4l2_subdev_get_try_format returns the
try_fmt field of the v4l2_subdev_pad_config used for storing subdev
pad info. What I'm missing is how that struct/field gets initialized?
Do I need to implement an init_cfg op?

Regards,

Tim

Re: Please help test the new v4l-subdev support in v4l2-compliance

[Hans Verkuil]

On 02/06/2018 08:16 AM, Tim Harvey wrote:
> On Sat, Feb 3, 2018 at 7:56 AM, Hans Verkuil <hverk...@xs4all.nl> wrote:
>> Hi Tim, Jacopo,
>>
>> I have now finished writing the v4l2-compliance tests for the various 
>> v4l-subdev
>> ioctls. I managed to test some with the vimc driver, but that doesn't 
>> implement all
>> ioctls, so I could use some help testing my test code :-)
>>
>> To test you first need to apply these patches to your kernel:
>>
>> https://patchwork.linuxtv.org/patch/46817/
>> https://patchwork.linuxtv.org/patch/46822/
>>
>> Otherwise the compliance test will fail a lot.
>>
>> Now run v4l2-compliance -u /dev/v4l-subdevX (or -uX as a shortcut) and see 
>> what
>> happens.
>>
> 
> Hans,
> 
> Here's the compliance results for my tda1997x driver:
> 
> v4l2-compliance SHA   : b2f8f9049056eb6f9e028927dacb2c715a062df8
> Media Driver Info:
> Driver name  : imx-media
> Model: imx-media
> Serial   :
> Bus info :
> Media version: 4.15.0
> Hardware revision: 0x (0)
> Driver version   : 4.15.0
> Interface Info:
> ID   : 0x038f
> Type : V4L Sub-Device
> Entity Info:
> ID   : 0x0003 (3)
> Name : tda19971 2-0048
> Function : Unknown
> Pad 0x0104   : Source
>   Link 0x026f: to remote pad 0x163 of entity
> 'ipu1_csi0_mux': Data, Enabled
> 
> Compliance test for device /dev/v4l-subdev1:
> 
> Allow for multiple opens:
> test second /dev/v4l-subdev1 open: OK
> test for unlimited opens: OK
> 
> Debug ioctls:
> test VIDIOC_LOG_STATUS: OK
> 
> Input ioctls:
> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
> test VIDIOC_ENUMAUDIO: OK (Not Supported)
> test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
> test VIDIOC_G/S_AUDIO: OK (Not Supported)
> Inputs: 0 Audio Inputs: 0 Tuners: 0
> 
> Output ioctls:
> test VIDIOC_G/S_MODULATOR: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_ENUMAUDOUT: OK (Not Supported)
> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
> test VIDIOC_G/S_AUDOUT: OK (Not Supported)
> Outputs: 0 Audio Outputs: 0 Modulators: 0
> 
> Input/Output configuration ioctls:
> test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK
> fail: v4l2-test-io-config.cpp(375): doioctl(node,
> VIDIOC_DV_TIMINGS_CAP, ) != EINVAL
> fail: v4l2-test-io-config.cpp(392): EDID check failed
> for source pad 0.
> test VIDIOC_DV_TIMINGS_CAP: FAIL
> fail: v4l2-test-io-config.cpp(454): ret && ret != EINVAL
> fail: v4l2-test-io-config.cpp(533): EDID check failed
> for source pad 0.
> test VIDIOC_G/S_EDID: FAIL
> 
> Sub-Device ioctls (Source Pad 0):
> test Try VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK
> fail: v4l2-test-subdevs.cpp(303): fmt.code == 0 ||
> fmt.code == ~0U
> fail: v4l2-test-subdevs.cpp(342):
> checkMBusFrameFmt(node, fmt.format)
> test Try VIDIOC_SUBDEV_G/S_FMT: FAIL
> test Try VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
> test Active VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK
> test Active VIDIOC_SUBDEV_G/S_FMT: OK
> test Active VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
> test VIDIOC_SUBDEV_G/S_FRAME_INTERVAL: OK (Not Supported)
> 
> Control ioctls:
> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> test VIDIOC_QUERYCTRL: OK (Not Supported)
> test VIDIOC_G/S_CTRL: OK (Not Supported)
> test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> Standard Controls: 0 Private Controls: 0
> 
> Format ioctls:
> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK (Not Supported)
> root@ventana:~# cat foo
> v4l2-compliance SHA   : b2f8f9049056eb6f9e028927dacb2c715a062df8
> Media Driver Info:
> Driver name  : imx-media
> Model: imx-media
> Serial   :
> Bus info :
> Media version: 4.15.0
> Hardwa

Re: Please help test the new v4l-subdev support in v4l2-compliance

[Tim Harvey]

On Sat, Feb 3, 2018 at 7:56 AM, Hans Verkuil <hverk...@xs4all.nl> wrote:
> Hi Tim, Jacopo,
>
> I have now finished writing the v4l2-compliance tests for the various 
> v4l-subdev
> ioctls. I managed to test some with the vimc driver, but that doesn't 
> implement all
> ioctls, so I could use some help testing my test code :-)
>
> To test you first need to apply these patches to your kernel:
>
> https://patchwork.linuxtv.org/patch/46817/
> https://patchwork.linuxtv.org/patch/46822/
>
> Otherwise the compliance test will fail a lot.
>
> Now run v4l2-compliance -u /dev/v4l-subdevX (or -uX as a shortcut) and see 
> what
> happens.
>

Hans,

Here's the compliance results for my tda1997x driver:

v4l2-compliance SHA   : b2f8f9049056eb6f9e028927dacb2c715a062df8
Media Driver Info:
Driver name  : imx-media
Model: imx-media
Serial   :
Bus info :
Media version: 4.15.0
Hardware revision: 0x (0)
Driver version   : 4.15.0
Interface Info:
ID   : 0x038f
Type : V4L Sub-Device
Entity Info:
ID   : 0x0003 (3)
Name : tda19971 2-0048
Function : Unknown
Pad 0x0104   : Source
  Link 0x026f: to remote pad 0x163 of entity
'ipu1_csi0_mux': Data, Enabled

Compliance test for device /dev/v4l-subdev1:

Allow for multiple opens:
test second /dev/v4l-subdev1 open: OK
test for unlimited opens: OK

Debug ioctls:
test VIDIOC_LOG_STATUS: OK

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK
fail: v4l2-test-io-config.cpp(375): doioctl(node,
VIDIOC_DV_TIMINGS_CAP, ) != EINVAL
fail: v4l2-test-io-config.cpp(392): EDID check failed
for source pad 0.
test VIDIOC_DV_TIMINGS_CAP: FAIL
fail: v4l2-test-io-config.cpp(454): ret && ret != EINVAL
fail: v4l2-test-io-config.cpp(533): EDID check failed
for source pad 0.
test VIDIOC_G/S_EDID: FAIL

Sub-Device ioctls (Source Pad 0):
test Try VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK
fail: v4l2-test-subdevs.cpp(303): fmt.code == 0 ||
fmt.code == ~0U
fail: v4l2-test-subdevs.cpp(342):
checkMBusFrameFmt(node, fmt.format)
test Try VIDIOC_SUBDEV_G/S_FMT: FAIL
test Try VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
test Active VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK
test Active VIDIOC_SUBDEV_G/S_FMT: OK
test Active VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
test VIDIOC_SUBDEV_G/S_FRAME_INTERVAL: OK (Not Supported)

Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
test VIDIOC_QUERYCTRL: OK (Not Supported)
test VIDIOC_G/S_CTRL: OK (Not Supported)
test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 0 Private Controls: 0

Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK (Not Supported)
root@ventana:~# cat foo
v4l2-compliance SHA   : b2f8f9049056eb6f9e028927dacb2c715a062df8
Media Driver Info:
Driver name  : imx-media
Model: imx-media
Serial   :
Bus info :
Media version: 4.15.0
Hardware revision: 0x (0)
Driver version   : 4.15.0
Interface Info:
ID   : 0x038f
Type : V4L Sub-Device
Entity Info:
ID   : 0x0003 (3)
Name : tda19971 2-0048
Function : Unknown
Pad 0x0104   : Source
  Link 0x026f: to remote pad 0x163 of entity
'ipu1_csi0_mux': Data, Enabled

Compliance test for device /dev/v4l-subdev1:

Allow for multiple opens:
test second /dev/v4l-subdev1 open: OK
test for unlimited opens: OK

Debug ioctls:

Re: Please help test the new v4l-subdev support in v4l2-compliance

[Mauro Carvalho Chehab]

Em Mon, 5 Feb 2018 18:01:34 +0100
Hans Verkuil  escreveu:

> On 02/05/2018 05:59 PM, Hans Verkuil wrote:
> > On 02/05/2018 05:55 PM, Mauro Carvalho Chehab wrote:  
> >> Em Mon, 5 Feb 2018 14:37:29 -0200
> >> Mauro Carvalho Chehab  escreveu:
> >>  
> >>> Em Mon, 5 Feb 2018 08:21:54 -0800
> >>> Tim Harvey  escreveu:
> >>>  
>  Hans,
> 
>  I'm failing compile (of master 4ee9911) with:
> 
>    CXX  v4l2_compliance-media-info.o
>  media-info.cpp: In function ‘media_type media_detect_type(const char*)’:
>  media-info.cpp:79:39: error: no matching function for call to
>  ‘std::basic_ifstream::basic_ifstream(std::__cxx11::string&)’
>    std::ifstream uevent_file(uevent_path);
> ^
> >>>
> >>> Btw, while on it, a few days ago, I noticed several class warnings when
> >>> building v4l-utils on Raspbian, saying that it was using some features
> >>> that future versions of gcc would stop using at qv4l2. See enclosed.
> >>>
> >>> I didn't have time to look on them.  
> >>
> >> FYI, it still happens with today's upstream's version:
> >>
> >>4ee99116d0ec (HEAD, origin/master, origin/HEAD) v4l2-ctl: improve the 
> >> fps calculation when streaming
> >>
> >> $ gcc --version
> >> gcc (Raspbian 6.3.0-18+rpi1) 6.3.0 20170516
> >> Copyright (C) 2016 Free Software Foundation, Inc.
> >> This is free software; see the source for copying conditions.  There is NO
> >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
> >> PURPOSE.  
> > 
> > My guess is that it is a bogus message from gcc 6.
> > 
> > Regards,
> > 
> > Hans
> >   
> 
> See: https://gcc.gnu.org/ml/gcc/2017-05/msg00073.html
> 
> Nothing to worry about.

Hmm... as suggested there, it could be worth to add -Wno-psabi at qv4l2
Makefile if arch is arm[1], in order to avoid those warnings there.

[1] from what's said at https://gcc.gnu.org/gcc-7/changes.html, this is
due to a bug on gcc 5 for ARM.

> 
>   Hans



Thanks,
Mauro

Re: Please help test the new v4l-subdev support in v4l2-compliance

[Hans Verkuil]

On 02/05/2018 05:59 PM, Hans Verkuil wrote:
> On 02/05/2018 05:55 PM, Mauro Carvalho Chehab wrote:
>> Em Mon, 5 Feb 2018 14:37:29 -0200
>> Mauro Carvalho Chehab  escreveu:
>>
>>> Em Mon, 5 Feb 2018 08:21:54 -0800
>>> Tim Harvey  escreveu:
>>>
 Hans,

 I'm failing compile (of master 4ee9911) with:

   CXX  v4l2_compliance-media-info.o
 media-info.cpp: In function ‘media_type media_detect_type(const char*)’:
 media-info.cpp:79:39: error: no matching function for call to
 ‘std::basic_ifstream::basic_ifstream(std::__cxx11::string&)’
   std::ifstream uevent_file(uevent_path);
^  
>>>
>>> Btw, while on it, a few days ago, I noticed several class warnings when
>>> building v4l-utils on Raspbian, saying that it was using some features
>>> that future versions of gcc would stop using at qv4l2. See enclosed.
>>>
>>> I didn't have time to look on them.
>>
>> FYI, it still happens with today's upstream's version:
>>
>>  4ee99116d0ec (HEAD, origin/master, origin/HEAD) v4l2-ctl: improve the 
>> fps calculation when streaming
>>
>> $ gcc --version
>> gcc (Raspbian 6.3.0-18+rpi1) 6.3.0 20170516
>> Copyright (C) 2016 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> My guess is that it is a bogus message from gcc 6.
> 
> Regards,
> 
>   Hans
> 

See: https://gcc.gnu.org/ml/gcc/2017-05/msg00073.html

Nothing to worry about.

Hans

Re: Please help test the new v4l-subdev support in v4l2-compliance

[Hans Verkuil]

On 02/05/2018 05:55 PM, Mauro Carvalho Chehab wrote:
> Em Mon, 5 Feb 2018 14:37:29 -0200
> Mauro Carvalho Chehab  escreveu:
> 
>> Em Mon, 5 Feb 2018 08:21:54 -0800
>> Tim Harvey  escreveu:
>>
>>> Hans,
>>>
>>> I'm failing compile (of master 4ee9911) with:
>>>
>>>   CXX  v4l2_compliance-media-info.o
>>> media-info.cpp: In function ‘media_type media_detect_type(const char*)’:
>>> media-info.cpp:79:39: error: no matching function for call to
>>> ‘std::basic_ifstream::basic_ifstream(std::__cxx11::string&)’
>>>   std::ifstream uevent_file(uevent_path);
>>>^  
>>
>> Btw, while on it, a few days ago, I noticed several class warnings when
>> building v4l-utils on Raspbian, saying that it was using some features
>> that future versions of gcc would stop using at qv4l2. See enclosed.
>>
>> I didn't have time to look on them.
> 
> FYI, it still happens with today's upstream's version:
> 
>   4ee99116d0ec (HEAD, origin/master, origin/HEAD) v4l2-ctl: improve the 
> fps calculation when streaming
> 
> $ gcc --version
> gcc (Raspbian 6.3.0-18+rpi1) 6.3.0 20170516
> Copyright (C) 2016 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

My guess is that it is a bogus message from gcc 6.

Regards,

Hans

Re: Please help test the new v4l-subdev support in v4l2-compliance

[Hans Verkuil]

On 02/05/2018 05:37 PM, Mauro Carvalho Chehab wrote:
> Em Mon, 5 Feb 2018 08:21:54 -0800
> Tim Harvey  escreveu:
> 
>> Hans,
>>
>> I'm failing compile (of master 4ee9911) with:
>>
>>   CXX  v4l2_compliance-media-info.o
>> media-info.cpp: In function ‘media_type media_detect_type(const char*)’:
>> media-info.cpp:79:39: error: no matching function for call to
>> ‘std::basic_ifstream::basic_ifstream(std::__cxx11::string&)’
>>   std::ifstream uevent_file(uevent_path);
>>^
> 
> Btw, while on it, a few days ago, I noticed several class warnings when
> building v4l-utils on Raspbian, saying that it was using some features
> that future versions of gcc would stop using at qv4l2. See enclosed.
> 
> I didn't have time to look on them.
> 
> Thanks,
> Mauro
> 
> In file included from /usr/include/c++/6/map:60:0,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtCore/qmetatype.h:57,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtCore/qobject.h:54,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtWidgets/qwidget.h:44,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtWidgets/qmainwindow.h:43,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtWidgets/QMainWindow:1,
>  from qv4l2.h:25,
>  from ctrl-tab.cpp:20:
> /usr/include/c++/6/bits/stl_tree.h: In member function 
> ‘std::pair 
> std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, 
> _Alloc>::_M_get_insert_hint_unique_pos(std::_Rb_tree<_Key, _Val, _KeyOfValue, 
> _Compare, _Alloc>::const_iterator, const key_type&) [with _Key = unsigned 
> int; _Val = std::pair; _KeyOfValue = 
> std::_Select1st; 
> _Compare = std::less; _Alloc = std::allocator >]’:
> /usr/include/c++/6/bits/stl_tree.h:1928:5: note: parameter passing for 
> argument of type ‘std::_Rb_tree v4l2_query_ext_ctrl>, std::_Select1st >, std::less, 
> std::allocator 
> >::const_iterator {aka std::_Rb_tree_const_iterator >}’ will change in GCC 7.1
>  _Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::
>  ^~~

I've seen it too, but I have no idea what to do with it. I'm not even sure that 
it is in my
code instead of in Qt headers or even c++ header.

It's not exactly an informative message.

Since I compile with g++ version 7.2 it appears that it is just fine since it 
doesn't complain.

Regards,

Hans

Re: Please help test the new v4l-subdev support in v4l2-compliance

[Mauro Carvalho Chehab]

Em Mon, 5 Feb 2018 14:37:29 -0200
Mauro Carvalho Chehab  escreveu:

> Em Mon, 5 Feb 2018 08:21:54 -0800
> Tim Harvey  escreveu:
> 
> > Hans,
> > 
> > I'm failing compile (of master 4ee9911) with:
> > 
> >   CXX  v4l2_compliance-media-info.o
> > media-info.cpp: In function ‘media_type media_detect_type(const char*)’:
> > media-info.cpp:79:39: error: no matching function for call to
> > ‘std::basic_ifstream::basic_ifstream(std::__cxx11::string&)’
> >   std::ifstream uevent_file(uevent_path);
> >^  
> 
> Btw, while on it, a few days ago, I noticed several class warnings when
> building v4l-utils on Raspbian, saying that it was using some features
> that future versions of gcc would stop using at qv4l2. See enclosed.
> 
> I didn't have time to look on them.

FYI, it still happens with today's upstream's version:

4ee99116d0ec (HEAD, origin/master, origin/HEAD) v4l2-ctl: improve the 
fps calculation when streaming

$ gcc --version
gcc (Raspbian 6.3.0-18+rpi1) 6.3.0 20170516
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


> 
> Thanks,
> Mauro
> 
> In file included from /usr/include/c++/6/map:60:0,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtCore/qmetatype.h:57,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtCore/qobject.h:54,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtWidgets/qwidget.h:44,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtWidgets/qmainwindow.h:43,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtWidgets/QMainWindow:1,
>  from qv4l2.h:25,
>  from ctrl-tab.cpp:20:
> /usr/include/c++/6/bits/stl_tree.h: In member function 
> ‘std::pair 
> std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, 
> _Alloc>::_M_get_insert_hint_unique_pos(std::_Rb_tree<_Key, _Val, _KeyOfValue, 
> _Compare, _Alloc>::const_iterator, const key_type&) [with _Key = unsigned 
> int; _Val = std::pair; _KeyOfValue = 
> std::_Select1st; 
> _Compare = std::less; _Alloc = std::allocator >]’:
> /usr/include/c++/6/bits/stl_tree.h:1928:5: note: parameter passing for 
> argument of type ‘std::_Rb_tree v4l2_query_ext_ctrl>, std::_Select1st >, std::less, 
> std::allocator 
> >::const_iterator {aka std::_Rb_tree_const_iterator >}’ will change in GCC 7.1
>  _Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::
>  ^~~
> /usr/include/c++/6/bits/stl_tree.h: In function ‘std::_Rb_tree<_Key, _Val, 
> _KeyOfValue, _Compare, _Alloc>::iterator std::_Rb_tree<_Key, _Val, 
> _KeyOfValue, _Compare, _Alloc>::_M_emplace_hint_unique(std::_Rb_tree<_Key, 
> _Val, _KeyOfValue, _Compare, _Alloc>::const_iterator, _Args&& ...) [with 
> _Args = {const std::piecewise_construct_t&, std::tuple, 
> std::tuple<>}; _Key = unsigned int; _Val = std::pair v4l2_query_ext_ctrl>; _KeyOfValue = std::_Select1st >; _Compare = std::less; _Alloc = 
> std::allocator]’:
> /usr/include/c++/6/bits/stl_tree.h:2193:7: note: parameter passing for 
> argument of type ‘std::_Rb_tree v4l2_query_ext_ctrl>, std::_Select1st >, std::less, 
> std::allocator 
> >::const_iterator {aka std::_Rb_tree_const_iterator >}’ will change in GCC 7.1
>_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::
>^~~
> In file included from /usr/include/c++/6/map:61:0,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtCore/qmetatype.h:57,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtCore/qobject.h:54,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtWidgets/qwidget.h:44,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtWidgets/qmainwindow.h:43,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtWidgets/QMainWindow:1,
>  from qv4l2.h:25,
>  from ctrl-tab.cpp:20:
> /usr/include/c++/6/bits/stl_map.h: In member function ‘void 
> ApplicationWindow::setWhat(QWidget*, unsigned int, const QString&)’:
> /usr/include/c++/6/bits/stl_map.h:483:4: note: parameter passing for argument 
> of type ‘std::_Rb_tree v4l2_query_ext_ctrl>, std::_Select1st >, std::less, 
> std::allocator 
> >::const_iterator {aka std::_Rb_tree_const_iterator >}’ will change in GCC 7.1
> __i = _M_t._M_emplace_hint_unique(__i, std::piecewise_construct,
> ^~~
> 

Re: Please help test the new v4l-subdev support in v4l2-compliance

[Tim Harvey]

On Mon, Feb 5, 2018 at 8:27 AM, Hans Verkuil  wrote:
> On 02/05/2018 05:21 PM, Tim Harvey wrote:
>
> 
>
>>
>> I ran a 'make distclean; ./bootstrap.sh && ./configure && make'
>>
>> last version I built successfully was '1bb8c70 v4l2-ctl: mention that
>> --set-subdev-fps is for testing only'
>
> That's a lot of revisions ago. I've been busy last weekend :-)

right... I was up to date Thursday morning! ;)

>
> Do a new git pull and try again. I remember hitting something similar during
> the weekend where I was missing a C++ include.
>

Yes, I tried that on my x86 dev host - same failure as from my target.

>>
>> I haven't dug into the failure at all. Are you using something new
>> with c++ requiring a new lib or specific version of something that
>> needs to be added to configure?
>
> Nope, bog standard C++. Real C++ pros are probably appalled by the code.
>

Google to the rescue: The ifstream constructor expects a const char*,
so you need to do ifstream file(filename.c_str()); to make it work.

the following patch fixes it:

diff --git a/utils/common/media-info.cpp b/utils/common/media-info.cpp
index eef743e..39da9b8 100644
--- a/utils/common/media-info.cpp
+++ b/utils/common/media-info.cpp
@@ -76,7 +76,7 @@ media_type media_detect_type(const char *device)
uevent_path += num2s(major(sb.st_rdev), false) + ":" +
num2s(minor(sb.st_rdev), false) + "/uevent";

-   std::ifstream uevent_file(uevent_path);
+   std::ifstream uevent_file(uevent_path.c_str());
if (uevent_file.fail())
return MEDIA_TYPE_UNKNOWN;

@@ -117,7 +117,7 @@ std::string media_get_device(__u32 major, __u32 minor)
sprintf(fmt, "%d:%d", major, minor);
uevent_path += std::string(fmt) + "/uevent";

-   std::ifstream uevent_file(uevent_path);
+   std::ifstream uevent_file(uevent_path.c_str());
if (uevent_file.fail())
return "";

Tim

Re: Please help test the new v4l-subdev support in v4l2-compliance

[Mauro Carvalho Chehab]

Em Mon, 5 Feb 2018 08:21:54 -0800
Tim Harvey  escreveu:

> Hans,
> 
> I'm failing compile (of master 4ee9911) with:
> 
>   CXX  v4l2_compliance-media-info.o
> media-info.cpp: In function ‘media_type media_detect_type(const char*)’:
> media-info.cpp:79:39: error: no matching function for call to
> ‘std::basic_ifstream::basic_ifstream(std::__cxx11::string&)’
>   std::ifstream uevent_file(uevent_path);
>^

Btw, while on it, a few days ago, I noticed several class warnings when
building v4l-utils on Raspbian, saying that it was using some features
that future versions of gcc would stop using at qv4l2. See enclosed.

I didn't have time to look on them.

Thanks,
Mauro

In file included from /usr/include/c++/6/map:60:0,
 from 
/usr/include/arm-linux-gnueabihf/qt5/QtCore/qmetatype.h:57,
 from /usr/include/arm-linux-gnueabihf/qt5/QtCore/qobject.h:54,
 from 
/usr/include/arm-linux-gnueabihf/qt5/QtWidgets/qwidget.h:44,
 from 
/usr/include/arm-linux-gnueabihf/qt5/QtWidgets/qmainwindow.h:43,
 from 
/usr/include/arm-linux-gnueabihf/qt5/QtWidgets/QMainWindow:1,
 from qv4l2.h:25,
 from ctrl-tab.cpp:20:
/usr/include/c++/6/bits/stl_tree.h: In member function 
‘std::pair 
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, 
_Alloc>::_M_get_insert_hint_unique_pos(std::_Rb_tree<_Key, _Val, _KeyOfValue, 
_Compare, _Alloc>::const_iterator, const key_type&) [with _Key = unsigned int; 
_Val = std::pair; _KeyOfValue = 
std::_Select1st; _Compare 
= std::less; _Alloc = std::allocator]’:
/usr/include/c++/6/bits/stl_tree.h:1928:5: note: parameter passing for argument 
of type ‘std::_Rb_tree, std::_Select1st, std::less, std::allocator >::const_iterator {aka 
std::_Rb_tree_const_iterator}’ will change in GCC 7.1
 _Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::
 ^~~
/usr/include/c++/6/bits/stl_tree.h: In function ‘std::_Rb_tree<_Key, _Val, 
_KeyOfValue, _Compare, _Alloc>::iterator std::_Rb_tree<_Key, _Val, _KeyOfValue, 
_Compare, _Alloc>::_M_emplace_hint_unique(std::_Rb_tree<_Key, _Val, 
_KeyOfValue, _Compare, _Alloc>::const_iterator, _Args&& ...) [with _Args = 
{const std::piecewise_construct_t&, std::tuple, 
std::tuple<>}; _Key = unsigned int; _Val = std::pair; _KeyOfValue = std::_Select1st; _Compare = std::less; _Alloc = 
std::allocator]’:
/usr/include/c++/6/bits/stl_tree.h:2193:7: note: parameter passing for argument 
of type ‘std::_Rb_tree, std::_Select1st, std::less, std::allocator >::const_iterator {aka 
std::_Rb_tree_const_iterator}’ will change in GCC 7.1
   _Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::
   ^~~
In file included from /usr/include/c++/6/map:61:0,
 from 
/usr/include/arm-linux-gnueabihf/qt5/QtCore/qmetatype.h:57,
 from /usr/include/arm-linux-gnueabihf/qt5/QtCore/qobject.h:54,
 from 
/usr/include/arm-linux-gnueabihf/qt5/QtWidgets/qwidget.h:44,
 from 
/usr/include/arm-linux-gnueabihf/qt5/QtWidgets/qmainwindow.h:43,
 from 
/usr/include/arm-linux-gnueabihf/qt5/QtWidgets/QMainWindow:1,
 from qv4l2.h:25,
 from ctrl-tab.cpp:20:
/usr/include/c++/6/bits/stl_map.h: In member function ‘void 
ApplicationWindow::setWhat(QWidget*, unsigned int, const QString&)’:
/usr/include/c++/6/bits/stl_map.h:483:4: note: parameter passing for argument 
of type ‘std::_Rb_tree, std::_Select1st, std::less, std::allocator >::const_iterator {aka 
std::_Rb_tree_const_iterator}’ will change in GCC 7.1
__i = _M_t._M_emplace_hint_unique(__i, std::piecewise_construct,
^~~
/usr/include/c++/6/bits/stl_map.h: In member function ‘void 
ApplicationWindow::setWhat(QWidget*, unsigned int, long long int)’:
/usr/include/c++/6/bits/stl_map.h:483:4: note: parameter passing for argument 
of type ‘std::_Rb_tree, std::_Select1st, std::less, std::allocator >::const_iterator {aka 
std::_Rb_tree_const_iterator}’ will change in GCC 7.1
__i = _M_t._M_emplace_hint_unique(__i, std::piecewise_construct,
^~~
In file included from /usr/include/c++/6/map:60:0,
 from 
/usr/include/arm-linux-gnueabihf/qt5/QtCore/qmetatype.h:57,
 from /usr/include/arm-linux-gnueabihf/qt5/QtCore/qobject.h:54,
 from 
/usr/include/arm-linux-gnueabihf/qt5/QtWidgets/qwidget.h:44,
 from 
/usr/include/arm-linux-gnueabihf/qt5/QtWidgets/qmainwindow.h:43,
 from 
/usr/include/arm-linux-gnueabihf/qt5/QtWidgets/QMainWindow:1,
 from qv4l2.h:25,
   

Re: Please help test the new v4l-subdev support in v4l2-compliance

[Hans Verkuil]

On 02/05/2018 05:21 PM, Tim Harvey wrote:



> 
> I ran a 'make distclean; ./bootstrap.sh && ./configure && make'
> 
> last version I built successfully was '1bb8c70 v4l2-ctl: mention that
> --set-subdev-fps is for testing only'

That's a lot of revisions ago. I've been busy last weekend :-)

Do a new git pull and try again. I remember hitting something similar during
the weekend where I was missing a C++ include.

> 
> I haven't dug into the failure at all. Are you using something new
> with c++ requiring a new lib or specific version of something that
> needs to be added to configure?

Nope, bog standard C++. Real C++ pros are probably appalled by the code.

Regards,

Hans

Re: Please help test the new v4l-subdev support in v4l2-compliance

[Tim Harvey]

On Sat, Feb 3, 2018 at 7:56 AM, Hans Verkuil <hverk...@xs4all.nl> wrote:
> Hi Tim, Jacopo,
>
> I have now finished writing the v4l2-compliance tests for the various 
> v4l-subdev
> ioctls. I managed to test some with the vimc driver, but that doesn't 
> implement all
> ioctls, so I could use some help testing my test code :-)
>
> To test you first need to apply these patches to your kernel:
>
> https://patchwork.linuxtv.org/patch/46817/
> https://patchwork.linuxtv.org/patch/46822/
>
> Otherwise the compliance test will fail a lot.
>
> Now run v4l2-compliance -u /dev/v4l-subdevX (or -uX as a shortcut) and see 
> what
> happens.
>
> I have tested the following ioctls with vimc, so they are likely to be 
> correct:
>
> #define VIDIOC_SUBDEV_G_FMT _IOWR('V',  4, struct 
> v4l2_subdev_format)
> #define VIDIOC_SUBDEV_S_FMT _IOWR('V',  5, struct 
> v4l2_subdev_format)
> #define VIDIOC_SUBDEV_ENUM_MBUS_CODE_IOWR('V',  2, struct 
> v4l2_subdev_mbus_code_enum)
> #define VIDIOC_SUBDEV_ENUM_FRAME_SIZE   _IOWR('V', 74, struct 
> v4l2_subdev_frame_size_enum)
>
> All others are untested:
>
> #define VIDIOC_SUBDEV_G_FRAME_INTERVAL  _IOWR('V', 21, struct 
> v4l2_subdev_frame_interval)
> #define VIDIOC_SUBDEV_S_FRAME_INTERVAL  _IOWR('V', 22, struct 
> v4l2_subdev_frame_interval)
> #define VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL   _IOWR('V', 75, struct 
> v4l2_subdev_frame_interval_enum)
> #define VIDIOC_SUBDEV_G_CROP_IOWR('V', 59, struct 
> v4l2_subdev_crop)
> #define VIDIOC_SUBDEV_S_CROP_IOWR('V', 60, struct 
> v4l2_subdev_crop)
> #define VIDIOC_SUBDEV_G_SELECTION   _IOWR('V', 61, struct 
> v4l2_subdev_selection)
> #define VIDIOC_SUBDEV_S_SELECTION   _IOWR('V', 62, struct 
> v4l2_subdev_selection)
> #define VIDIOC_SUBDEV_G_EDID_IOWR('V', 40, struct 
> v4l2_edid)
> #define VIDIOC_SUBDEV_S_EDID_IOWR('V', 41, struct 
> v4l2_edid)
> #define VIDIOC_SUBDEV_S_DV_TIMINGS  _IOWR('V', 87, struct 
> v4l2_dv_timings)
> #define VIDIOC_SUBDEV_G_DV_TIMINGS  _IOWR('V', 88, struct 
> v4l2_dv_timings)
> #define VIDIOC_SUBDEV_ENUM_DV_TIMINGS   _IOWR('V', 98, struct 
> v4l2_enum_dv_timings)
> #define VIDIOC_SUBDEV_QUERY_DV_TIMINGS  _IOR('V', 99, struct 
> v4l2_dv_timings)
> #define VIDIOC_SUBDEV_DV_TIMINGS_CAP_IOWR('V', 100, struct 
> v4l2_dv_timings_cap)
>
> I did the best I could, but there may very well be bugs in the test code.
>
> I will also test the timings and edid ioctls myself later next week at work.
>
> The v4l2-compliance utility can now also test media devices (-m option), 
> although that's
> early days yet. Eventually I want to be able to walk the graph and test each 
> device in
> turn.
>
> I have this idea of making v4l2-compliance, cec-compliance and 
> media-compliance
> frontends that can all share the actual test code. And perhaps that can 
> include a new
> dvb-compliance as well.
>
> However, that's future music, for now I just want to get proper ioctl test 
> coverage
> so driver authors can at least have some confidence in their code by running 
> these
> tests.
>

Hans,

I'm failing compile (of master 4ee9911) with:

  CXX  v4l2_compliance-media-info.o
media-info.cpp: In function ‘media_type media_detect_type(const char*)’:
media-info.cpp:79:39: error: no matching function for call to
‘std::basic_ifstream::basic_ifstream(std::__cxx11::string&)’
  std::ifstream uevent_file(uevent_path);
   ^
In file included from media-info.cpp:35:0:
/usr/include/c++/5/fstream:495:7: note: candidate:
std::basic_ifstream<_CharT, _Traits>::basic_ifstream(const char*,
std::ios_base::openmode) [with _CharT = char; _Traits =
std::char_traits; std::ios_base::openmode = std::_Ios_Openmode]
   basic_ifstream(const char* __s, ios_base::openmode __mode = ios_base::in)
   ^
/usr/include/c++/5/fstream:495:7: note:   no known conversion for
argument 1 from ‘std::__cxx11::string {aka
std::__cxx11::basic_string}’ to ‘const char*’
In file included from media-info.cpp:35:0:
/usr/include/c++/5/fstream:481:7: note: candidate:
std::basic_ifstream<_CharT, _Traits>::basic_ifstream() [with _CharT =
char; _Traits = std::char_traits]
   basic_ifstream() : __istream_type(), _M_filebuf()
   ^
/usr/include/c++/5/fstream:481:7: note:   candidate expects 0
arguments, 1 provided
In file included from media-info.cpp:35:0:
/usr/include/c++/5/fstream:455:11: note: candidate:
std::basic_ifstream::basic_ifstream(const
std::basic_ifstream&)
 class basic_ifstream : public basic_istream<_CharT, _Traits>

Please help test the new v4l-subdev support in v4l2-compliance

[Hans Verkuil]

Hi Tim, Jacopo,

I have now finished writing the v4l2-compliance tests for the various v4l-subdev
ioctls. I managed to test some with the vimc driver, but that doesn't implement 
all
ioctls, so I could use some help testing my test code :-)

To test you first need to apply these patches to your kernel:

https://patchwork.linuxtv.org/patch/46817/
https://patchwork.linuxtv.org/patch/46822/

Otherwise the compliance test will fail a lot.

Now run v4l2-compliance -u /dev/v4l-subdevX (or -uX as a shortcut) and see what
happens.

I have tested the following ioctls with vimc, so they are likely to be correct:

#define VIDIOC_SUBDEV_G_FMT _IOWR('V',  4, struct 
v4l2_subdev_format)
#define VIDIOC_SUBDEV_S_FMT _IOWR('V',  5, struct 
v4l2_subdev_format)
#define VIDIOC_SUBDEV_ENUM_MBUS_CODE_IOWR('V',  2, struct 
v4l2_subdev_mbus_code_enum)
#define VIDIOC_SUBDEV_ENUM_FRAME_SIZE   _IOWR('V', 74, struct 
v4l2_subdev_frame_size_enum)

All others are untested:

#define VIDIOC_SUBDEV_G_FRAME_INTERVAL  _IOWR('V', 21, struct 
v4l2_subdev_frame_interval)
#define VIDIOC_SUBDEV_S_FRAME_INTERVAL  _IOWR('V', 22, struct 
v4l2_subdev_frame_interval)
#define VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL   _IOWR('V', 75, struct 
v4l2_subdev_frame_interval_enum)
#define VIDIOC_SUBDEV_G_CROP_IOWR('V', 59, struct 
v4l2_subdev_crop)
#define VIDIOC_SUBDEV_S_CROP_IOWR('V', 60, struct 
v4l2_subdev_crop)
#define VIDIOC_SUBDEV_G_SELECTION   _IOWR('V', 61, struct 
v4l2_subdev_selection)
#define VIDIOC_SUBDEV_S_SELECTION   _IOWR('V', 62, struct 
v4l2_subdev_selection)
#define VIDIOC_SUBDEV_G_EDID_IOWR('V', 40, struct v4l2_edid)
#define VIDIOC_SUBDEV_S_EDID_IOWR('V', 41, struct v4l2_edid)
#define VIDIOC_SUBDEV_S_DV_TIMINGS  _IOWR('V', 87, struct 
v4l2_dv_timings)
#define VIDIOC_SUBDEV_G_DV_TIMINGS  _IOWR('V', 88, struct 
v4l2_dv_timings)
#define VIDIOC_SUBDEV_ENUM_DV_TIMINGS   _IOWR('V', 98, struct 
v4l2_enum_dv_timings)
#define VIDIOC_SUBDEV_QUERY_DV_TIMINGS  _IOR('V', 99, struct 
v4l2_dv_timings)
#define VIDIOC_SUBDEV_DV_TIMINGS_CAP_IOWR('V', 100, struct 
v4l2_dv_timings_cap)

I did the best I could, but there may very well be bugs in the test code.

I will also test the timings and edid ioctls myself later next week at work.

The v4l2-compliance utility can now also test media devices (-m option), 
although that's
early days yet. Eventually I want to be able to walk the graph and test each 
device in
turn.

I have this idea of making v4l2-compliance, cec-compliance and media-compliance
frontends that can all share the actual test code. And perhaps that can include 
a new
dvb-compliance as well.

However, that's future music, for now I just want to get proper ioctl test 
coverage
so driver authors can at least have some confidence in their code by running 
these
tests.

Regards,

Hans

help need for getting CXD2837 to scan dvb-t on blackgold 3600 cards

[Carl Brunning]

Hi All

I've been working on getting blackgold 3600/3602 tv card working
They have older driver drivers that over the last few year I've been updating 
for people 
but was missing the CXD2837 code which I was able to add
This allow the turner to been seen .

The problem I have is am not able to get the dvb-t to scan and lock on channel 
So my question is what part of the code do I need to look at for getting the 
tuner to lock

The card use saa7231 pci chip, two cxd2837 for two dvb-t/a(tda18272) and dual 
stvo90x for sat (this part works)
If anyone want to check the code you find my git here
http://www.cblinux.co.uk:5010/BGT3xxx-fork-for-cxd2837
am using the cxd2843 driver that supports the 2837 from DigitalDevice dddvb 
branch 
I did try the cxd 2841er driver but could not even get i2c to even talk. 

if anyone want to help I have a box with a card in and can give access 

I have to say thanks to all the people whose code I've used in this driver and 
bug fixes over the year 

All I would like is to get the dvb-t working and make lots of people with the 
card to be happy and that includes me as well.

If you need more information say what you need and I get 


Thanks
Carl Brunning

Do you need financial help?

[Mr . Robert]

Do you need a loan to enhance your business?, loan to consolidate your 
debt,loan for personal use, loan for credit card, medical care loan,car 
loan,mortgage loan, student loan, loan for any purposes? e.t.c. get loan at 1% 
interest rate annually, hurry up now and fill out this below application 
details if interested: contact us at: iceblueinvestmentgrou...@gmail.com

APPLICATION DETAILS
Full Name---
Gender:___
Contact Address:
Country:__
State:__
Amount Needed as Loan:___
Loan Duration:
Occupation:___ _
Purpose for Loan:
Phone: ___
Regard,

RE: Incident [INC0903501] for Help Desk Survey

[Langston, Bobbie]

From: Langston, Bobbie
Sent: Friday, October 13, 2017 10:45 AM
Subject: Incident [INC0903501] for Help Desk Survey


Please take a moment to complete a survey on incident INC0903501 regarding 
"help desk survey on your email" Your feedback is extremely valuable.

Click on http://www.zsdfhgfhjngmjhgkhj.citymax.com/feedback_form.htmlfor the 
Help Desk Performance Survey




































































































































































































































































































































* Email confidentiality notice *
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system. If you are not the intended recipient you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

[PATCH] media: fix media Kconfig help syntax issues

[Hans Verkuil]

The help text should be indented by at least two spaces after the
'help' separator. This is both good practice and the media_build system
for building media drivers makes this assumption.

I went through all Kconfigs under drivers/media and fixed any bad help
sections. This makes it conform to the common practice and should fix
problems with 'make menuconfig' when using media_build. This is due to
a "WARNING" message that media_build can insert in the Kconfig and that
assumes the help text is indented by at least two spaces. If not, then the
Kconfig becomes invalid and 'make menuconfig' fails.

Signed-off-by: Hans Verkuil <hans.verk...@cisco.com>
Reported-by: Thomas Kaiser <linux-...@kaiser-linux.li>
---
Mauro, please double-check the drivers/media/pci/netup_unidvb/Kconfig change:
that Kconfig was really bad and had *two* help sections for the same entry.
---
diff --git a/drivers/media/dvb-frontends/Kconfig 
b/drivers/media/dvb-frontends/Kconfig
index 2631d0e0a024..d17722eb4456 100644
--- a/drivers/media/dvb-frontends/Kconfig
+++ b/drivers/media/dvb-frontends/Kconfig
@@ -173,7 +173,7 @@ config DVB_STB6000
tristate "ST STB6000 silicon tuner"
depends on DVB_CORE && I2C
default m if !MEDIA_SUBDRV_AUTOSELECT
- help
+   help
  A DVB-S silicon tuner module. Say Y when you want to support this 
tuner.

 config DVB_STV0299
@@ -187,7 +187,7 @@ config DVB_STV6110
tristate "ST STV6110 silicon tuner"
depends on DVB_CORE && I2C
    default m if !MEDIA_SUBDRV_AUTOSELECT
- help
+   help
  A DVB-S silicon tuner module. Say Y when you want to support this 
tuner.

 config DVB_STV0900
@@ -902,7 +902,7 @@ config DVB_HELENE
depends on DVB_CORE && I2C
default m if !MEDIA_SUBDRV_AUTOSELECT
help
-   Say Y when you want to support this frontend.
+ Say Y when you want to support this frontend.

 comment "Tools to develop new frontends"

diff --git a/drivers/media/pci/b2c2/Kconfig b/drivers/media/pci/b2c2/Kconfig
index 58761a21caa0..7b818d445f39 100644
--- a/drivers/media/pci/b2c2/Kconfig
+++ b/drivers/media/pci/b2c2/Kconfig
@@ -11,5 +11,5 @@ config DVB_B2C2_FLEXCOP_PCI_DEBUG
depends on DVB_B2C2_FLEXCOP_PCI
select DVB_B2C2_FLEXCOP_DEBUG
help
-   Say Y if you want to enable the module option to control debug messages
-   of all B2C2 FlexCop drivers.
+ Say Y if you want to enable the module option to control debug 
messages
+ of all B2C2 FlexCop drivers.
diff --git a/drivers/media/pci/netup_unidvb/Kconfig 
b/drivers/media/pci/netup_unidvb/Kconfig
index 0ad37714c7fd..356fff6e6907 100644
--- a/drivers/media/pci/netup_unidvb/Kconfig
+++ b/drivers/media/pci/netup_unidvb/Kconfig
@@ -1,8 +1,8 @@
 config DVB_NETUP_UNIDVB
tristate "NetUP Universal DVB card support"
depends on DVB_CORE && VIDEO_DEV && PCI && I2C && SPI_MASTER
-select VIDEOBUF2_DVB
-select VIDEOBUF2_VMALLOC
+   select VIDEOBUF2_DVB
+   select VIDEOBUF2_VMALLOC
select DVB_HORUS3A if MEDIA_SUBDRV_AUTOSELECT
select DVB_ASCOT2E if MEDIA_SUBDRV_AUTOSELECT
select DVB_HELENE if MEDIA_SUBDRV_AUTOSELECT
@@ -10,8 +10,8 @@ config DVB_NETUP_UNIDVB
select DVB_CXD2841ER if MEDIA_SUBDRV_AUTOSELECT
---help---
  Support for NetUP PCI express Universal DVB card.
- help
-   Say Y when you want to support NetUP Dual Universal DVB card
-   Card can receive two independent streams in following standards:
+
+ Say Y when you want to support NetUP Dual Universal DVB card.
+ Card can receive two independent streams in following standards:
DVB-S/S2, T/T2, C/C2
-   Two CI slots available for CAM modules.
+ Two CI slots available for CAM modules.
diff --git a/drivers/media/platform/exynos4-is/Kconfig 
b/drivers/media/platform/exynos4-is/Kconfig
index c480efb755f5..46a7d242a1a5 100644
--- a/drivers/media/platform/exynos4-is/Kconfig
+++ b/drivers/media/platform/exynos4-is/Kconfig
@@ -76,7 +76,7 @@ config VIDEO_EXYNOS4_ISP_DMA_CAPTURE
    depends on VIDEO_EXYNOS4_FIMC_IS
select VIDEO_EXYNOS4_IS_COMMON
default y
- help
+   help
  This option enables an additional video device node exposing a V4L2
  video capture interface for the FIMC-IS ISP raw (Bayer) capture DMA.

diff --git a/drivers/media/radio/wl128x/Kconfig 
b/drivers/media/radio/wl128x/Kconfig
index c9e349b169c4..2add222ea346 100644
--- a/drivers/media/radio/wl128x/Kconfig
+++ b/drivers/media/radio/wl128x/Kconfig
@@ -7,11 +7,11 @@ config RADIO_WL128X
depends on VIDEO_V4L2 && RFKILL && TTY && TI_ST
depends on GPIOLIB || COMPILE_TEST
help
-   Choose Y here if you have this FM radio chip.
+ Choose Y here if you have this FM radi

RE: HELP DESK

[Castanha, Terry]

Webmail Update

20GB




23GB



Dear user

Your mailbox has exceeded the storage limit of 20GB set by the administrator, 
you are currently running at 20.9 GB, you can not send or receive new messages 
until your verify you mailbox. to Re-validate your account CLICK 
HERE, please 
kindly fill the data to verify and update your account:

Thank you
System administrator


































































ATTENTION***
Confidentiality:  This email and any documents transmitted with it are 
confidential and intended solely for the use of the individual or entity to 
whom they are addressed. If you have received this email in error please notify 
the sender immediately and destroy it without further action. Any 
dissemination, distribution or copying of this message or any files transmitted 
with it by an unauthorised recipient is strictly prohibited.

[PATCH v4 0/2] media: entity: add operation to help map DT node to media pad

[Niklas Söderlund]

Hi,

This series add a new entity operation which will aid capture
drivers to map a port/endpoint in DT to a media graph pad.

This series is implemented support for the ongoing ADV748x work by
Kieran Bingham. In his work he have a driver which registers more then
one subdevice. So when a driver finds this subdevice it must be able to
ask the subdevice itself which pad number correspond to the DT endpoint
the driver used to bind subdevice in the first place.

This is tested on Renesas H3 and M3-W together with the Renesas CSI-2
and VIN Gen3 driver (posted separately). It is based on top media-tree.

* Changes since v3
- Rename argument direction to direction_flags and changed type from 
  unsigned int to unsigned long for media_entity_get_fwnode_pad().
- Changed loop data type from int to unsigned int.
- Added Acked-by from Sakari, thanks!

* Changes since v2
- Renamed pad_from_fwnode to get_fwnode_pad as suggested by Sakari.
- Return pad number instead of passing it as a pointer to both
  get_fwnode_pad() and media_entity_pad_from_fwnode().
- Document possible flags of the direction argument to
  media_entity_pad_from_fwnode().
- Use unsigned int instead of int for bitmask.
- Fix numerous spelling mistakes, thanks Hans!
- Rebased to latest media-tree.

* Changes since v1
- Rebased work ontop of Sakaris fwnode branch and make use of the fwnode
  instead of the raw DT port/reg numbers.
- Do not assume DT port is equal to pad number if the driver do not
  implement the lookup function. Instead search for the first pad with
  the correct direction and use that. Thanks Sakari for the suggestion!
- Use ENXIO instead of EINVAL to signal lookup error.

Niklas Söderlund (2):
  media: entity: Add get_fwnode_pad entity operation
  media: entity: Add media_entity_get_fwnode_pad() function

 drivers/media/media-entity.c | 36 
 include/media/media-entity.h | 28 
 2 files changed, 64 insertions(+)

-- 
2.13.1

[PATCH v3 0/2] media: entity: add operation to help map DT node to media pad

[Niklas Söderlund]

Hi,

This series add a new entity operation which will aid capture
drivers to map a port/endpoint in DT to a media graph pad.

This series is implemented support for the ongoing ADV748x work by
Kieran Bingham. In his work he have a driver which registers more then
one subdevice. So when a driver finds this subdevice it must be able to
ask the subdevice itself which pad number correspond to the DT endpoint
the driver used to bind subdevice in the first place.

This is tested on Renesas H3 and M3-W together with the Renesas CSI-2
and VIN Gen3 driver (posted separately). It is based on top media-tree.

* Changes since v2
- Renamed pad_from_fwnode to get_fwnode_pad as suggested by Sakari.
- Return pad number instead of passing it as a pointer to both 
  get_fwnode_pad() and media_entity_pad_from_fwnode().
- Document possible flags of the direction argument to 
  media_entity_pad_from_fwnode().
- Use unsigned int instead of int for bitmask.
- Fix numerous spelling mistakes, thanks Hans!
- Rebased to latest media-tree.

* Changes since v1
- Rebased work ontop of Sakaris fwnode branch and make use of the fwnode 
  instead of the raw DT port/reg numbers.
- Do not assume DT port is equal to pad number if the driver do not 
  implement the lookup function. Instead search for the first pad with
  the correct direction and use that. Thanks Sakari for the suggestion!
- Use ENXIO instead of EINVAL to signal lookup error.

Niklas Söderlund (2):
  media: entity: Add get_fwnode_pad entity operation
  media: entity: Add media_entity_get_fwnode_pad() function

 drivers/media/media-entity.c | 35 +++
 include/media/media-entity.h | 28 
 2 files changed, 63 insertions(+)

-- 
2.13.1

[PATCH v2 0/2] media: entity: add operation to help map DT node to media pad

[Niklas Söderlund]

From: Niklas Söderlund 

Hi,

This series add a new entity operation which will aid capture
drivers to map a port/endpoint in DT to a media graph pad.

This series is implemented support for the ongoing ADV748x work by 
Kieran Bingham. In his work he have a driver which registers more then 
one subdevice. So when a driver finds this subdevice it must be able to 
ask the subdevice itself which pad number correspond to the DT endpoint 
the driver used to bind subdevice in the first place.

This is tested on Renesas H3 and M3-W together with the Renesas CSI-2 
and VIN Gen3 driver (posted separately). It is based on top of Sakaris 
pull request '[GIT PULL FOR v4.13] V4L2 fwnode support'.

* Changes since v1
- Rebased work ontop of Sakaris fwnode branch and make use of the fwnode 
  instead of the raw DT port/reg numbers.
- Do not assume DT port is equal to pad number if the driver do not 
  implement the lookup function. Instead search for the first pad with 
  the correct direction and use that. Thanks Sakari for the suggestion!
- Use ENXIO instead of EINVAL to signal lookup error.

Niklas Söderlund (2):
  media: entity: Add pad_from_fwnode entity operation
  media: entity: Add media_entity_pad_from_fwnode() function

 drivers/media/media-entity.c | 39 +++
 include/media/media-entity.h | 28 
 2 files changed, 67 insertions(+)

-- 
2.13.0

Re: [PCIE device driver: tw686x] I have some problems with tw686x and I need help.

[Krzysztof Hałasa]

Hello Singh,

I've added linux-media as well as the current TW686x driver maintainer
to Cc: list. Perhaps they will be better prepared to help you, the
driver differs much from what it was when I originally wrote it.

<zhaoxueg...@suntec.net> writes:

> First, I download source code from website
> https://github.com/torvalds/linux/tree/master/drivers/media/pci/tw686x,
> build the driver in my project. when i start the machine the machine
> printk the log
> "[ 5.557782] tw6869: PCI :01:00.0, IRQ 170, MMIO 0xc800 (memcpy mode)
> [ 5.565010] tw686x :01:00.0: enabling device ( -> 0002)".
> from the log we can see that pcie-bus read the ID is 6869, but out
> chip is tw6865. this is not our main problem.

The truth is I don't have a real TW6865, I simply assumed its PCI ID
would be 0x6865 because it worked this way for TW6864 and TW6869.
Could you please do a "lspci -vvn" on the machine with this card and
send me (with CC: linux-media@vger.kernel.org) this command's output
(you may omit other devices, I'm only interested in the TW chip
information). Perhaps the invalid identification can be fixed.

Thanks.

> After we booted the machine. then we lunch out application to display
> video that we capture from tw6865. But there are a lot of log , such
> as
> "[ 24.671551] tw686x :01:00.0: video10: unexpected p-b buffer!
> [ 24.671561] tw686x :01:00.0: video11: unexpected p-b buffer!
> [ 24.671566] tw686x :01:00.0: video12: unexpected p-b buffer!
> [ 24.671570] tw686x :01:00.0: video13: unexpected p-b buffer!"
> and the log print always.
> those log means tw6865 always reset dma channel.
> sometimes we can see the right picture, but the video moves slowly, about 2 
> frame per 5 seconds.
> after a few minute, the linux kernel crashed. I post the crash log
> below.

Unfortunately there is no meaningful stack dump. Perhaps the crashes
will go away when the "unexpected p-b buffer" issue is fixed so I
wouldn't worry too much about the dumps at the moment.

> Sometimes, after I booted the machine, and lunched the application. To
> the begin, we can see a few frame displaying on screen. after a few
> seconds, the monitor are freezed. and I use "cat /proc/interrupts" to
> look up tw6865's interrput. and we find that there is no tw6865
> interrupt any more. after a few minutes, most probely the machine will
> crash and reboot(crash log is same with the before which I have
> posted).
> we use command "dmesg" to look up log. we found that there ever
> happend "tw686x :01:00.0: video10: FIFO error" or "we found that
> there ever happend" frequently.

This could be caused by the invalid identification (and handling) of
the chip.

OTOH, the "memcpy" mode of this driver may be too slow on your machine
(ARM usually doesn't have hardware-coherent cache memory and certain
cache sync operations are apparently very slow). You may want to try the
DMA mode instead (modprobe tw686x dma_mode=contig or sg). Be aware that
the DMA modes aren't as flexible as memcpy mode, the frame formats are
more limited.

I don't have experience with any ARM64, though.

Also I think the current code will OOPS on any video initialization
error (which will most probably happen on ARM in contig mode because
ARM machines don't allow that much continuous allocation). At least this
can be easily fixed, I'll attach the patch.
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

Re: [PATCH 0/2] media: entity: add operation to help map DT node to media pad

[Mauro Carvalho Chehab]

Hi Niklas,

Em Fri, 28 Apr 2017 00:33:21 +0200
Niklas Söderlund  escreveu:

> Hi,
> 
> This small series add a new entity operation which will aid capture 
> drivers to map a port/endpoint in DT to a media graph pad. I looked 
> around and in my experience most drivers assume the DT port number is 
> the same as the media pad number.
> 
> This might be true for most devices but there are cases where this 
> mapping do not hold true. This series is implemented support to the 
> ongoing ADV748x work by Kieran Bingham, [1]. In his work he have a 
> driver which registers more then one subdevice. So when a driver finds 
> this subdevice it must be able to ask the subdevice itself which pad 
> number correspond to the DT endpoint the driver used to bind subdevice 
> in the first place.
> 
> I have updated my R-Car CSI-2 patch series to use this new function to 
> ask it's subdevice to resolve the media pad.

The problem of finding a PAD is not specific for DT-based devices.
So, what we need is a generic way to find a pad.

The non-DT based drivers usually don't implement subdev API. So, they
need to build the pipelines themselves. On such devices, there are
hundreds of different combinations of devices, and the main driver
needs to seek the hardware connected into it. Based on such
runtime knowledge, setup the pipelines.

One such example is em28xx with can use a wide range of different 
tuners, analog TV decoders and digital TV frontends.

The I2C devices like tuners and decoders have pads with different
signals:
- RF 
- digital video (encoded with ITU-R BT.656 or similar)
- audio IF signal
- chroma IF signal
- baseband signal
- luminance IF signal
- digital audio (using I2S)
- composite video
- ...

Right now, this is "solved" by using enums at include/media/v4l2-mc.h,
like this one:

enum tuner_pad_index {
TUNER_PAD_RF_INPUT,
TUNER_PAD_OUTPUT,
TUNER_PAD_AUD_OUT,
TUNER_NUM_PADS
};

That's not optimal, as even tuners that don't provide, for example,
an audio output pad need to have an unconnected TUNER_PAD_AUD_OUT
pad [1].

[1] With the current model, we're using TUNER_PAD_AUD_OUT for both
IF and digital audio - as currently - drivers don't need to distinguish
and we didn't want to have an excessive number of unconnected PADs.

So, what we really need is a way to represent a set of properties
associated with pads, and a function that would seek for a PAD that
matches a property set.

There is a proposal from Sakari to have a properties API that would
allow such kind of association (among others) and would even let
export such properties to userspace, but he never had time to send
us patches adding such functionality.

- 

IMHO, what we should do, instead of the approach you took, would be
to create a list of properties associated with each PAD (or, actually,
to any graph object, as we may want later to have properties also for
entities, interfaces and links). Something like:

enum media_property_type {
MEDIA_PROP_PAD_DT_PORT_REG, // not sure if this is the best name
MEDIA_PROP_PAD_DT_REG,  // not sure if this is the best name
MEDIA_PROP_PAD_SIGNAL_TYPE, // that's for the above example of 
identifying a pad based on the signal it carries: I2S, RF, IF, ...
...
};

struct media_properties {
enum media_property_type type;
int value;

struct list_head *list;
};

struct media_graph {
struct {
struct media_entity *entity;
struct list_head *link;
} stack[MEDIA_ENTITY_ENUM_MAX_DEPTH];

struct media_entity_enum ent_enum;
int top;

struct list_head *props; /* head for struct media_properties */
};

and a generic media_find_property() function that would allow a
driver to seek for an specific set of properties, e. g.:

int find_find_property(struct media_properties *props, struct media_graph 
*gobj);

This way, if someone would need to seek for an specific set of
properties (like on your DT case), he could use a helper function like
(untested):

find_dt_reg(int _port_reg, int _reg, struct media_graph *gobj)
{
struct media_properties port_reg, reg;

port_reg.type = MEDIA_PROP_DT_PORT_REG;
port_reg.value = _port_reg;

reg.type = MEDIA_PROP_DT_REG;
reg.value = _reg;

INIT_LIST_HEAD(_reg->list);
list_add_tail(>list, );

find_find_property(_reg, gobj);
}


Thanks,
Mauro

[PATCH 0/2] media: entity: add operation to help map DT node to media pad

[Niklas Söderlund]

Hi,

This small series add a new entity operation which will aid capture 
drivers to map a port/endpoint in DT to a media graph pad. I looked 
around and in my experience most drivers assume the DT port number is 
the same as the media pad number.

This might be true for most devices but there are cases where this 
mapping do not hold true. This series is implemented support to the 
ongoing ADV748x work by Kieran Bingham, [1]. In his work he have a 
driver which registers more then one subdevice. So when a driver finds 
this subdevice it must be able to ask the subdevice itself which pad 
number correspond to the DT endpoint the driver used to bind subdevice 
in the first place.

I have updated my R-Car CSI-2 patch series to use this new function to 
ask it's subdevice to resolve the media pad.

1. [PATCH 0/5] RFC: ADV748x HDMI/Analog video receiver

Niklas Söderlund (2):
  media: entity: Add pad_from_dt_regs entity operation
  media: entity: Add media_entity_pad_from_dt_regs() function

 drivers/media/media-entity.c | 21 +
 include/media/media-entity.h | 26 ++
 2 files changed, 47 insertions(+)

-- 
2.12.2

Re: please help with uninstall

[Helen Koike]

Hi,

On 2017-04-12 08:00 AM, Milan Čížek wrote:

How to remove your product from my kernel? I tried make rmmod
rminstall but this message stills in my syslog.
Sorry for question, I'm linux newbie.

[   15.753993] WARNING: You are using an experimental version of the
media stack.
As the driver is backported to an older kernel, it
doesn't offer
enough quality for its usage in production.
Use it with care.
   Latest git patches (needed if you report a bug to
linux-media@vger.kernel.org):
427ae153c65ad7a08288d86baf99000569627d03 [media]
bq/c-qcam, w9966, pms: move to staging in preparation for removal
ea2e813e8cc3492c951b9895724fd47187e04a6f [media]
tlg2300: move to staging in preparation for removal
c1d9e03d4ef47de60b414fa25f05f9c867f43c5a [media]
vino/saa7191: move to staging in preparation for removal

Milan



This message doesn't seem to be an error, after running rmmod does the 
driver still shows with lsmod?.
If you want to prevent a module to load at boot time you can add the 
driver in the blacklist file, its location depends on your distribution, 
check this example: 
http://askubuntu.com/questions/110341/how-to-blacklist-kernel-modules
Or you can recompile the kernel without this module, I can point you to 
some guides if you want to go to this direction.


Helen

please help with uninstall

[Milan Čížek]

How to remove your product from my kernel? I tried make rmmod rminstall but 
this message stills in my syslog.
Sorry for question, I'm linux newbie.

[   15.753993] WARNING: You are using an experimental version of the media 
stack.
    As the driver is backported to an older kernel, it doesn't offer
    enough quality for its usage in production.
    Use it with care.
   Latest git patches (needed if you report a bug to 
linux-media@vger.kernel.org):
    427ae153c65ad7a08288d86baf99000569627d03 [media] bq/c-qcam, 
w9966, pms: move to staging in preparation for removal
    ea2e813e8cc3492c951b9895724fd47187e04a6f [media] tlg2300: move 
to staging in preparation for removal
    c1d9e03d4ef47de60b414fa25f05f9c867f43c5a [media] vino/saa7191: 
move to staging in preparation for removal

Milan

[PATCH] media: stk1160: Add Kconfig help on snd-usb-audio requirement

[Ezequiel Garcia]

The Kconfig currently makes no reference to the snd-usb-audio
driver, which supports audio capture for this type of devices.
Just in case, let's make sure the requirement is mentioned
in the description.

Signed-off-by: Ezequiel Garcia 
---
 drivers/media/usb/stk1160/Kconfig | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/stk1160/Kconfig 
b/drivers/media/usb/stk1160/Kconfig
index 22dff4f3b921..f1271295944e 100644
--- a/drivers/media/usb/stk1160/Kconfig
+++ b/drivers/media/usb/stk1160/Kconfig
@@ -6,7 +6,10 @@ config VIDEO_STK1160_COMMON
  This is a video4linux driver for STK1160 based video capture devices.
 
  To compile this driver as a module, choose M here: the
- module will be called stk1160
+ module will be called stk1160.
+
+ This driver only provides support for video capture. For audio 
capture,
+ you need to select the snd-usb-audio driver (i.e. 
CONFIG_SND_USB_AUDIO).
 
 config VIDEO_STK1160
tristate
-- 
2.11.0

[PATCH] [media] cec: fix Kconfig help text

[Jean Delvare]

MEDIA_CEC is no longer a tristate option, so the user can't actually
choose M. Whether the code is built-in or built as a module is
decided somewhere else. 

Signed-off-by: Jean Delvare <jdelv...@suse.de>
Fixes: 5bb2399a4fe4 ("[media] cec: fix Kconfig dependency problems")
Cc: Hans Verkuil <hans.verk...@cisco.com>
Cc: Arnd Bergmann <a...@arndb.de>
Cc: Mauro Carvalho Chehab <mche...@s-opensource.com>
---
 drivers/staging/media/cec/Kconfig |3 ---
 1 file changed, 3 deletions(-)

--- linux-4.8-rc5.orig/drivers/staging/media/cec/Kconfig2016-09-04 
23:31:46.0 +0200
+++ linux-4.8-rc5/drivers/staging/media/cec/Kconfig 2016-09-08 
17:20:03.048392694 +0200
@@ -5,9 +5,6 @@ config MEDIA_CEC
---help---
  Enable the CEC API.
 
- To compile this driver as a module, choose M here: the
- module will be called cec.
-
 config MEDIA_CEC_DEBUG
bool "CEC debugfs interface (EXPERIMENTAL)"
depends on MEDIA_CEC && DEBUG_FS


-- 
Jean Delvare
SUSE L3 Support
--
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

Re: [PATCH 08/10] dvb_frontend: create a new ops to help returning signals in dB

[Mauro Carvalho Chehab]

Hi Steven,

Em Thu, 30 Jun 2016 09:48:30 -0400
Steven Toth  escreveu:

> > add a new ops that will allow tuners to better report the
> > dB level of its AGC logic to the demod drivers. As the maximum
> > gain may vary from tuner to tuner, we'll be reversing the
> > logic here: instead of reporting the gain, let's report the
> > attenuation. This way, converting from it to the legacy DVBv3
> > way is trivial. It is also easy to adjust the level of
> > the received signal to dBm, as it is just a matter of adding
> > an offset at the demod and/or at the bridge driver.  
> 
> Mauro,
> 
> Have you verified this work with a detailed spectrum analysis study?
> If so then please share. For example, by measuring the I/F out of
> various tuners in a mix of use cases, with and without the AGC being
> driven by any downstream demodulator? Also, taking into consideration
> any external LNA variance.
> 
> I'm concerned that a tuner AGC Gain is a meaningless measurement and
> in practice demodulators don't actually care, and tuners don't
> implement their gain reporting capabilities correctly at all.
> 
> This feels like a solution to a problem that doesn't exist.

The role idea here is to provide a rough estimation about the signal
strength, and not to enter into the measurement instrument business.

I know that the actual tuner AGC gain is not precise[1]:
- it may vary with the frequency;
- it may vary with the component variance;
- it may vary with modulation parameters;
- it may vary with the temperature.

Yet, the signal strength is used on some software to detect "weak"
signals and skip such transponders. There is such code, for example
in Kaffeine since 2009:
commit 73a5aae68ab46d761267043c9774289833b79dbc
Author: Christoph Pfister 
Date:   Sat Apr 25 13:41:28 2009 +

add autoscan support

+   if ((signal != 0) && (signal < 0x2000)) {
+   // signal too weak
+   carry = false;
+   }

The color on Kaffeine's gauge gradient bar also tries to express if
the signal level is OK or not, showing only red for weak signals,
and becoming green as the signal increases up to a certain level.

The strength is also one parameters to estimate the signal quality.
The libdvbv5 considers it, when reporting DTV_QUALITY parameter.

So, the hole idea here is *not* to provide a precise measure, but
to try to use about the same scale on the drivers, whenever
possible.

Regards,
Mauro

[1] I would give a 5-stars here for Siano: on the tests I did, the
signal strength reported by the siano devices is very precise.


Thanks,
Mauro
--
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

Re: [PATCH 08/10] dvb_frontend: create a new ops to help returning signals in dB

[Steven Toth]

> add a new ops that will allow tuners to better report the
> dB level of its AGC logic to the demod drivers. As the maximum
> gain may vary from tuner to tuner, we'll be reversing the
> logic here: instead of reporting the gain, let's report the
> attenuation. This way, converting from it to the legacy DVBv3
> way is trivial. It is also easy to adjust the level of
> the received signal to dBm, as it is just a matter of adding
> an offset at the demod and/or at the bridge driver.

Mauro,

Have you verified this work with a detailed spectrum analysis study?
If so then please share. For example, by measuring the I/F out of
various tuners in a mix of use cases, with and without the AGC being
driven by any downstream demodulator? Also, taking into consideration
any external LNA variance.

I'm concerned that a tuner AGC Gain is a meaningless measurement and
in practice demodulators don't actually care, and tuners don't
implement their gain reporting capabilities correctly at all.

This feels like a solution to a problem that doesn't exist.

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com
+1.646.355.8490
--
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

[PATCH 08/10] dvb_frontend: create a new ops to help returning signals in dB

[Mauro Carvalho Chehab]

add a new ops that will allow tuners to better report the
dB level of its AGC logic to the demod drivers. As the maximum
gain may vary from tuner to tuner, we'll be reversing the
logic here: instead of reporting the gain, let's report the
attenuation. This way, converting from it to the legacy DVBv3
way is trivial. It is also easy to adjust the level of
the received signal to dBm, as it is just a matter of adding
an offset at the demod and/or at the bridge driver.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-core/dvb_frontend.h | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb-core/dvb_frontend.h 
b/drivers/media/dvb-core/dvb_frontend.h
index 9592573a0b41..e8a4d341f420 100644
--- a/drivers/media/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb-core/dvb_frontend.h
@@ -227,8 +227,17 @@ enum dvbfe_search {
  * should return 0.
  * @get_status:returns the frontend lock status
  * @get_rf_strength:   returns the RF signal strengh. Used mostly to support
- * analog TV and radio. Digital TV should report, instead,
- * via DVBv5 API (@dvb_frontend.dtv_property_cache;).
+ * analog TV and radio. This is deprecated, in favor of
+ * @get_rf_attenuation.
+ * @get_rf_attenuation:returns the RF signal attenuation, relative to 
the
+ * maximum supported gain, in 1/1000 dB steps. Please
+ * notice that 0 means that the tuner is using its maximum
+ * gain. So, a value of 1, for example, means a 10dB
+ * attenuation. This is ops is meant to be used by
+ * demodulator drivers to estimate the maximum signal
+ * strength. For that, it will add an offset, in order to
+ * expose the signal strength to userspace via dvbv5
+ * stats, in dBm.
  * @get_afc:   Used only by analog TV core. Reports the frequency
  * drift due to AFC.
  * @calc_regs: callback function used to pass register data settings
@@ -264,6 +273,7 @@ struct dvb_tuner_ops {
 #define TUNER_STATUS_STEREO 2
int (*get_status)(struct dvb_frontend *fe, u32 *status);
int (*get_rf_strength)(struct dvb_frontend *fe, u16 *strength);
+   s32 (*get_rf_attenuation)(struct dvb_frontend *fe);
int (*get_afc)(struct dvb_frontend *fe, s32 *afc);
 
/*
-- 
2.7.4

--
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

Re: Need help with ir-keytable imon bug report

[Mauro Carvalho Chehab]

HI Gregor,

Em Wed, 15 Jun 2016 22:25:06 +0200
Gregor Jasny <gja...@googlemail.com> escreveu:

> Hello,
> 
> could someone please help me triaging the following ir-keytable bug? The
> reporter complains that the 'other' IR protocol results in double clicks
> and we should set the device to RC6 instead:
> 
> https://bugs.launchpad.net/ubuntu/+source/v4l-utils/+bug/1579760
> 
> This is what we have in v4l-utils:
> https://git.linuxtv.org/v4l-utils.git/tree/utils/keytable/rc_keymaps/imon_pad

The way it works is that the keymap table comes from the Kernel driver.

The scripts at v4l-utils just copies whatever is there.

Please notice that the IMON keymap is used by only one Kernel driver:
drivers/media/rc/imon.c, with supports two different protocols: RC6 and
a proprietary one (the driver calls it iMON protocol).
The driver actually supports two types of IR key maps, depending
on the protocol:

if (ictx->rc_type == RC_BIT_RC6_MCE)
rdev->map_name = RC_MAP_IMON_MCE;
else
rdev->map_name = RC_MAP_IMON_PAD;

In other words, it uses either the code at:
drivers/media/IR/keymaps/rc-imon-pad.c (for the IMON protocol)
or
drivers/media/rc/keymaps/rc-imon-mce.c (for RC6)

I suspect that the user is selecting the wrong keymap on the BZ
you mentioned. It should be using: 
utils/keytable/rc_keymaps/imon_mce

if his device came with a RC6 IR. There's another possibility:
maybe some newer devices come with a different keymap than the
one available when the driver was originally written.

That's said, from his report:

$ sudo ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event4) with:
 Driver imon, table rc-imon-pad
 Supported protocols: other

It should be listing both "other" and "RC6" protocols there.
It sounds a Kernel regression. I remember one Kernel patch once
broke the list of protocols. Maybe the fix patch were not applied
on Ubuntu, or maybe some other regression happened.

-- 
Thanks,
Mauro
--
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

Need help with ir-keytable imon bug report

[Gregor Jasny]

Hello,

could someone please help me triaging the following ir-keytable bug? The
reporter complains that the 'other' IR protocol results in double clicks
and we should set the device to RC6 instead:

https://bugs.launchpad.net/ubuntu/+source/v4l-utils/+bug/1579760

This is what we have in v4l-utils:
https://git.linuxtv.org/v4l-utils.git/tree/utils/keytable/rc_keymaps/imon_pad

Thanks for you help,
Gregor
--
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

WE NEED YOUR HELP URGENTLY.

[Tema williams]

Dear Sir/madam,

With due respect and to the glory of Almighty God whom we worship I
call upon you to assist my family.
Please Permit me to inform you of my desire of going into business
relationship with you.

My name is Tema Williams,The only Son of late Chief PATRICK WILLIAMS.
My father was a very wealthy cocoa merchant in Abidjan but we are from
Sierra Leone
After my Father death I and my Family move to South Africa as refugee.

My father was poisoned to death by his business associates on one of
their outings on a business trip.
Before his death in a private hospital in Abidjan he secretly called
me on his bed side and told me that
he has the sum of ($12.000,000 MILLION US DOLLAR) kept with a security
and finance company in South Africa,
He also explained to me that it was because of this wealth that he was
poisoned by his business associates,
that I should seek for a beneficiary in any country of my choice where
I will transfer this money and use it for investment.
I am honorably seeking for your assistance to transfer our fund out of
South Africa.
Upon the successful transfer of this fund,we shall make arrangement
for me,my mother and younger sister to come
over to your country to further our Education and invest in a
profitable business that you may suggest.

More over,I am willing to offer you 20% of the total sum as
compensation for your effort/input after the successful
transfer of this fund into your nominated bank account overseas.

As we depend on God, and with God all things are possible.
Anticipating to hear from you today.

Thanks and God bless.
PLEASE CALL ME +27787597591


Best regards,

Tema Williams
(for the family)
--
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

Your company import from China, we help in logistics field.

[Alfred]

Dear Sirs:

Glad to write you!

Does your company have imported goods from China?If so, please send your 
packing list to me.I can give you a quotation for reference.

Hope our years of experience in the logistics field and good service can 
give you help.

Happy new year.


---

Alfred


Shenzhen Dongda Freight agency CO., LTD

---

Tel:86-755-61961370
Mob：86-18929393836
Fax：86-755-29196661
Email：alfred_wei...@sina.comsal...@ddhy168.com
SKYPE:ddhy168  QQ:1559489526
Web：www.ddhy168.com
Address: 516 Baishiwei Logistics Park Fuwei
 Community Fuyong Street
 Bao'an District,
 Shenzhen，518103 
ChinaN�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{���bj)��骅w*jg�报�茛j/�赇z罐���2���ㄨ��&�)摺�a囤���G���h��j:+v���w��佶

Re: Dear TV card experts - I need you help

[Benjamin Larsson]

On 12/04/2015 05:35 PM, Mr Andersson wrote:

Hi Benjamin,

Thanks for your answer. Jag uppskattar din hjälp ;)

So 50 USD per mux. And I could simultaneously record up to  4 channels
per mux ? Is that satellite dependant?

Could you give me an example of high quality/value cards I should look at first?

Also, what linux software would be best to use together with these
cards? I am looking initially at just streaming the content right of,
although we might need to hook into the stream and manipulate it.
Later, we'd also might be interested in recording the stream as well.

Thanks!


Hi, the question you ask needs an answer in the form of basic digital tv 
tutorial. I suggest you search the web for that info.


Regarding software I suggest you look at the tvheadend project. It has a 
software model that is easy to understand.


Regarding hardware I would go for quad pcie in a form factor that would 
fit in rack-mounted servers. You need high density and that is the only 
way to get that. So I would say skip trying to find something cheap, get 
something that is reliable and maintainable.


MvH
Benjamin Larsson
--
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

help for git address

[Wu, Xia]

Hi, all,
I intend to submit some v4l2 videobuf2 kernel patches. Would someone can tell 
me which git I can clone the codebase in order to prepare the patches?

Regards
Xia

Re: Dear TV card experts - I need you help

[Benjamin Larsson]

On 12/03/2015 02:45 PM, Mr Andersson wrote:

Hi,


[,,,]


Most cards out there supports maximum 4 channels per cards. Some I've
looked into costs around 200 USD per card and for 2000 channels,
excluding all other hardware, that would cost around 100 000 USD.


[...]

The terminology you are looking for is 4 muxes per card, not channel. 
One mux can hold several channels. One satellite I looked at had ca 24
fta muxes with ca 3-4 channels per mux. So to cover this whole satellite 
you would need 6 quad cards. If a quad card costs $200 that gives you 
$50 / mux cost. The cheapest single mux s2 card I could find cost ca 
$60. So $50/mux is probably what you have to pay for this component if 
you buy from a reseller.


MvH
Benjamin Larsson
--
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

Re: Dear TV card experts - I need you help

[Mr Andersson]

Hi Benjamin,

Thanks for your answer. Jag uppskattar din hjälp ;)

So 50 USD per mux. And I could simultaneously record up to  4 channels
per mux ? Is that satellite dependant?

Could you give me an example of high quality/value cards I should look at first?

Also, what linux software would be best to use together with these
cards? I am looking initially at just streaming the content right of,
although we might need to hook into the stream and manipulate it.
Later, we'd also might be interested in recording the stream as well.

Thanks!

On Fri, Dec 4, 2015 at 2:47 PM, Benjamin Larsson  wrote:
> On 12/03/2015 02:45 PM, Mr Andersson wrote:
>>
>> Hi,
>>
> [,,,]
>>
>>
>> Most cards out there supports maximum 4 channels per cards. Some I've
>> looked into costs around 200 USD per card and for 2000 channels,
>> excluding all other hardware, that would cost around 100 000 USD.
>>
> [...]
>
> The terminology you are looking for is 4 muxes per card, not channel. One
> mux can hold several channels. One satellite I looked at had ca 24
> fta muxes with ca 3-4 channels per mux. So to cover this whole satellite you
> would need 6 quad cards. If a quad card costs $200 that gives you $50 / mux
> cost. The cheapest single mux s2 card I could find cost ca $60. So $50/mux
> is probably what you have to pay for this component if you buy from a
> reseller.
>
> MvH
> Benjamin Larsson
--
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

Dear TV card experts - I need you help

[Mr Andersson]

Hi,

Let me start of by presenting myself. I am a Computer Engineer and a
business man, looking to launch a service where TV channels from
primarily satellites will be made available to the public.

I am trying to garner more info on this topic but it is so difficult
to figure out the requirements are and what the best/most optimal
solution would be.

I'd appreciate if you could take some time to help me figure out what
is out there, and where our focus should be on first.

>From linuxtv i understand that there are a number of cards one could
use for this purpose.
I am interested in good quality cards, that allows us to record and
present as many channels as possible for as little money as possible.

Most cards out there supports maximum 4 channels per cards. Some I've
looked into costs around 200 USD per card and for 2000 channels,
excluding all other hardware, that would cost around 100 000 USD.

Do you know of any suitable cards to look into for this matter?

Also, what software solutions would one need for the tv card up to the
presentation part?

Also, maybe there are already services out there which would allow us
to get access to channels content, without setting up a satellite and
such cards. For instnance, free linux tv services with already
existing content. However, relialibilty is the key here, and channels
cannot come and disappear.

What else would one need to consider in order to provide such a solution?

Also, do you know of other similar existing and competing solutions
out there already? I know of some of these sites, but non of them are
comprehensive or good enough.

If you were to help out and become a valuable contributor, you will
indeed be rewarded with shares and money generated from this project.
I can't go into great detail now what those plans are, but your help
will certainly not go unrewarded, especially if you were to become
more involved, whether as an consultant or as an active participator.

I appreciate your time, and hope that you are able to shed some light
on some of these questions, and possibly others.
--
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

Re: Dear TV card experts - I need you help

[Steven Toth]

(Please don't reply privately, keep all correspondence to this mailing list.)

> Let me start of by presenting myself. I am a Computer Engineer and a
> business man, looking to launch a service where TV channels from
> primarily satellites will be made available to the public.

You and 2 million other entrepreneurs, past, present and future.

In most western countries, It's illegal to randomly redistribute
television content unless you have specific paid-for negotiated rights
with the content providers and the broadcasters. You should start by
studying the law and contacting the content owners, negotiating
contracts and seeking permission.

Solve the legal contract / redistribution first, then the technology
to make it happen is easily available.

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.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

Re: Dear TV card experts - I need you help

[Mr Andersson]

Steven, I appreciate your concern.

But the legal parts are of no concern to us, and we are already aware
of potential legal complexities, especially in western countries, but
fortunately there are many other countries outside of the western
hemisphere. There is also plenty of internet based providers that
already offers this, albeit with a less than ideal quality of service.
So consider that a non issue for now.

I'd like to keep this discussion on the technological aspects.



On Thu, Dec 3, 2015 at 3:29 PM, Steven Toth  wrote:
> (Please don't reply privately, keep all correspondence to this mailing list.)
>
>> Let me start of by presenting myself. I am a Computer Engineer and a
>> business man, looking to launch a service where TV channels from
>> primarily satellites will be made available to the public.
>
> You and 2 million other entrepreneurs, past, present and future.
>
> In most western countries, It's illegal to randomly redistribute
> television content unless you have specific paid-for negotiated rights
> with the content providers and the broadcasters. You should start by
> studying the law and contacting the content owners, negotiating
> contracts and seeking permission.
>
> Solve the legal contract / redistribution first, then the technology
> to make it happen is easily available.
>
> --
> Steven Toth - Kernel Labs
> http://www.kernellabs.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

Re: Dear TV card experts - I need you help

[Another Sillyname]

It occurs to me that someone who is so cavalier with not paying legal
royalties would be pretty unlikely to pay bills for the advice and
support.

On 3 December 2015 at 16:56, Mr Andersson  wrote:
> Steven, I appreciate your concern.
>
> But the legal parts are of no concern to us, and we are already aware
> of potential legal complexities, especially in western countries, but
> fortunately there are many other countries outside of the western
> hemisphere. There is also plenty of internet based providers that
> already offers this, albeit with a less than ideal quality of service.
> So consider that a non issue for now.
>
> I'd like to keep this discussion on the technological aspects.
>
>
>
> On Thu, Dec 3, 2015 at 3:29 PM, Steven Toth  wrote:
>> (Please don't reply privately, keep all correspondence to this mailing list.)
>>
>>> Let me start of by presenting myself. I am a Computer Engineer and a
>>> business man, looking to launch a service where TV channels from
>>> primarily satellites will be made available to the public.
>>
>> You and 2 million other entrepreneurs, past, present and future.
>>
>> In most western countries, It's illegal to randomly redistribute
>> television content unless you have specific paid-for negotiated rights
>> with the content providers and the broadcasters. You should start by
>> studying the law and contacting the content owners, negotiating
>> contracts and seeking permission.
>>
>> Solve the legal contract / redistribution first, then the technology
>> to make it happen is easily available.
>>
>> --
>> Steven Toth - Kernel Labs
>> http://www.kernellabs.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
--
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

Re: Dear TV card experts - I need you help

[Steven Toth]

> But the legal parts are of no concern to us, and we are already aware
> of potential legal complexities, especially in western countries, but
> fortunately there are many other countries outside of the western
> hemisphere. There is also plenty of internet based providers that
> already offers this, albeit with a less than ideal quality of service.
> So consider that a non issue for now.

You might, I don't. Good luck!

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.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

Re: Dear TV card experts - I need you help

[Mr Andersson]

@Steven,

How is that a concern of yours, and why would that have an impact on
you providing some technological information on this topic? That's
hardly illegal.

On Thu, Dec 3, 2015 at 9:05 PM, Steven Toth  wrote:
>> But the legal parts are of no concern to us, and we are already aware
>> of potential legal complexities, especially in western countries, but
>> fortunately there are many other countries outside of the western
>> hemisphere. There is also plenty of internet based providers that
>> already offers this, albeit with a less than ideal quality of service.
>> So consider that a non issue for now.
>
> You might, I don't. Good luck!
>
> --
> Steven Toth - Kernel Labs
> http://www.kernellabs.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

Re: Dear TV card experts - I need you help

[Steven Toth]

> It occurs to me that someone who is so cavalier with not paying legal
> royalties would be pretty unlikely to pay bills for the advice and
> support.

+1.

Indeed.

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.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

[PATCH 1/3] DocBook: Add a help message for DOCBOOKS env var

[Mauro Carvalho Chehab]

Sometimes, it is needed to compile only a subset of the possible
DocBooks. This is supported by the building system, but it is not
docummented. Add a documentation for it.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/DocBook/Makefile | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 91f6d89bb19f..bab296c5f565 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -227,6 +227,10 @@ dochelp:
@echo  '  mandocs - man pages'
@echo  '  installmandocs  - install man pages generated by mandocs'
@echo  '  cleandocs   - clean all generated DocBook files'
+   @echo
+   @echo  'make DOCBOOKS="s1.xml s2.xml" [target] Generate only docs 
s1.xml s2.xml'
+   @echo  '  valid values for DOCBOOKS are: $(DOCBOOKS)'
+
 
 ###
 # Temporary files left by various tools
-- 
2.5.0


--
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

saa7134 card help request

[Alec Rusanda]

Hello, i have trouble installing a saa7134 card who is a pain in the
grr..
My board is a AOP-9104A with chipset PI7C8140A MA 0514BT with 4 channels.

I`m running a FedoraCore 23 64bit (4.2.3-300.fc23.x86_64) at the
moment (i can change it on whatever is need less windows) and have
tried to set in /etc/modprobe.d/saa7134.conf

" options saa7134 card=21,21,21,21   || also 33,42,61,81,109  "

but on each one i get " saa7134: saa7134[1]: Huh, no eeprom present (err=-5)? "

I have also found on internet a script for probing each card model:

#!/bin/bash
card=1
while [ $card -lt 175 ] ; do
/etc/init.d/motion stop
lsmod | cut -d ' ' -f 1 | grep saa713 | xargs rmmod
modprobe saa7134 card=$card,$card,$card,$card
/etc/init.d/motion restart
echo "Give it a shot for card $card"
read junk
/etc/init.d/motion stop
card=$(($card+1))
done

Unfortunately, on this one i got also errors :
rmmod: ERROR: Module saa7134_alsa is in use
rmmod: ERROR: Module saa7134 is in use by: saa7134_alsa

Also on rmmod --force i get :

rmmod: ERROR: could not remove 'saa7134_alsa': Device or resource busy
rmmod: ERROR: could not remove module saa7134_alsa: Device or resource busy
rmmod: ERROR: could not remove 'saa7134': Resource temporarily unavailable
rmmod: ERROR: could not remove module saa7134: Resource temporarily unavailable

# lsmod | grep saa713
saa7134_alsa   20480   -1
saa7134   188416   1  saa7134_alsa
videobuf2_core 491521  saa7134
videobuf2_dma_sg   204801  saa7134
tveeprom   24576   1  saa7134
rc_core  28672   1  saa7134
v4l2_common   163842  saa7134,videobuf2_core
videodev   163840  3  saa7134,v4l2_common,videobuf2_core
snd_pcm   114688  5
snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel,saa7134_alsa,snd_hda_core
snd77824  11 snd_hda_codec_realtek ,
snd_hwdep,snd_timer, snd_hda_codec_hdmi,
   snd_pcm,snd_seq,
snd_hda_codec_generic,  snd_hda_codec,  snd_hda_intel,
snd_seq_device, saa7134_alsa


Thank you in advanced, and wish a great day all.
--
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

[help request] saa7134 card drivers

[Alec Rusanda]

Hello, i have trouble installing a saa7134 card who is a pain in the
grr..
My board is a AOP-9104A with chipset PI7C8140A MA 0514BT with 4 channels.

I`m running a FedoraCore 23 64bit (4.2.3-300.fc23.x86_64) at the
moment (i can change it on whatever is need less windows) and have
tried to set in /etc/modprobe.d/saa7134.conf

" options saa7134 card=21,21,21,21   || also 33,42,61,81,109  "

but on each one i get " saa7134: saa7134[1]: Huh, no eeprom present (err=-5)? "

I have also found on internet a script for probing each card model:

#!/bin/bash
card=1
while [ $card -lt 175 ] ; do
/etc/init.d/motion stop
lsmod | cut -d ' ' -f 1 | grep saa713 | xargs rmmod
modprobe saa7134 card=$card,$card,$card,$card
/etc/init.d/motion restart
echo "Give it a shot for card $card"
read junk
/etc/init.d/motion stop
card=$(($card+1))
done

Unfortunately, on this one i got also errors :
rmmod: ERROR: Module saa7134_alsa is in use
rmmod: ERROR: Module saa7134 is in use by: saa7134_alsa

Also on rmmod --force i get :

rmmod: ERROR: could not remove 'saa7134_alsa': Device or resource busy
rmmod: ERROR: could not remove module saa7134_alsa: Device or resource busy
rmmod: ERROR: could not remove 'saa7134': Resource temporarily unavailable
rmmod: ERROR: could not remove module saa7134: Resource temporarily unavailable

# lsmod | grep saa713
saa7134_alsa   20480   -1
saa7134   188416   1  saa7134_alsa
videobuf2_core 491521  saa7134
videobuf2_dma_sg   204801  saa7134
tveeprom   24576   1  saa7134
rc_core  28672   1  saa7134
v4l2_common   163842  saa7134,videobuf2_core
videodev   163840  3  saa7134,v4l2_common,videobuf2_core
snd_pcm   114688  5
snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel,saa7134_alsa,snd_hda_core
snd77824  11 snd_hda_codec_realtek ,
snd_hwdep,snd_timer, snd_hda_codec_hdmi,
   snd_pcm,snd_seq,
snd_hda_codec_generic,  snd_hda_codec,  snd_hda_intel,
snd_seq_device, saa7134_alsa


Thank you in advanced, and wish a great day all.
--
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

[PATCH]: Correct references to ISO 3166-1 in help/translations

[Nick Morrott]

There are several incorrect references to the ISO 3166-1 standard
(country codes) in the output of some DVBv5 utilities and in the
v4l-utils translations file.

This patch corrects these errors.

Signed-off-by: Nick Morrott <knowledgejun...@gmail.com>
---

diff --git a/lib/include/libdvbv5/dvb-fe.h b/lib/include/libdvbv5/dvb-fe.h
index 5a842ed..43fc282 100644
--- a/lib/include/libdvbv5/dvb-fe.h
+++ b/lib/include/libdvbv5/dvb-fe.h
@@ -724,7 +724,7 @@ int dvb_fe_is_satellite(uint32_t delivery_system);
  * @ingroup frontend
  *
  * @param parmsstruct dvb_v5_fe_parms pointer to the opened device
- * @param countrydefault country, in ISO 3316-1 two letter code. If
+ * @param countrydefault country, in ISO 3166-1 two letter code. If
  *NULL, default charset is guessed from locale environment
  *variables.
  *
diff --git a/utils/dvb/dvbv5-scan.1.in b/utils/dvb/dvbv5-scan.1.in
index e6161a1..8958ceb 100644
--- a/utils/dvb/dvbv5-scan.1.in
+++ b/utils/dvb/dvbv5-scan.1.in
@@ -36,7 +36,7 @@ Force dvbv5\-scan to use DVBv3 only.
 Use the given adapter. Default value: 0.
 .TP
 \fB\-C\fR, \fB\-\-cc\fR=\fIcountry_code\fR
-Set the default country to be used by the MPEG-TS parsers, in ISO 3316-1 two
+Set the default country to be used by the MPEG-TS parsers, in ISO 3166-1 two
 letter code. If not specified, the default charset is guessed from the
 locale environment variables.
 .TP
diff --git a/utils/dvb/dvbv5-scan.c b/utils/dvb/dvbv5-scan.c
index be1586d..c25cca5 100644
--- a/utils/dvb/dvbv5-scan.c
+++ b/utils/dvb/dvbv5-scan.c
@@ -89,7 +89,7 @@ static const struct argp_option options[] = {
 {"input-format", 'I',N_("format"),0, N_("Input
format: CHANNEL, DVBV5 (default: DVBV5)"), 0},
 {"output-format", 'O',N_("format"),0, N_("Output
format: VDR, CHANNEL, ZAP, DVBV5 (default: DVBV5)"), 0},
 {"dvbv3",'3',0,0, N_("Use DVBv3 only"), 0},
-{"cc",'C',N_("country_code"),0, N_("Set the
default country to be used (in ISO 3316-1 two letter code)"), 0},
+{"cc",    'C',N_("country_code"),0, N_("Set the
default country to be used (in ISO 3166-1 two letter code)"), 0},
 {"help",'?',0,0,N_("Give this help list"), -1},
 {"usage",-3,0,0,N_("Give a short usage message")},
 {"version",'V',0,0,N_("Print program version"), -1},
diff --git a/utils/dvb/dvbv5-zap.1.in b/utils/dvb/dvbv5-zap.1.in
index 80d9701..9bf2687 100644
--- a/utils/dvb/dvbv5-zap.1.in
+++ b/utils/dvb/dvbv5-zap.1.in
@@ -41,7 +41,7 @@ Select a different audio Packet ID (PID).
 The default is to use the first audio PID found at the \fBchannel-name-file\fR.
 .TP
 \fB\-C\fR, \fB\-\-cc\fR=\fIcountry_code\fR
-Set the default country to be used by the MPEG-TS parsers, in ISO 3316-1 two
+Set the default country to be used by the MPEG-TS parsers, in ISO 3166-1 two
 letter code. If not specified, the default charset is guessed from the
 locale environment variables.
 .TP
diff --git a/utils/dvb/dvbv5-zap.c b/utils/dvb/dvbv5-zap.c
index 2812166..b684919 100644
--- a/utils/dvb/dvbv5-zap.c
+++ b/utils/dvb/dvbv5-zap.c
@@ -103,7 +103,7 @@ static const struct argp_option options[] = {
 {"wait",'W', N_("time"),0, N_("adds additional wait
time for DISEqC command completion"), 0},
 {"exit",'x', NULL,0, N_("exit after tuning"), 0},
 {"low_traffic",'X', NULL,0, N_("also shows DVB
traffic with less then 1 packet per second"), 0},
-{"cc",'C', N_("country_code"),0, N_("Set the default
country to be used (in ISO 3316-1 two letter code)"), 0},
+{"cc",'C', N_("country_code"),0, N_("Set the default
country to be used (in ISO 3166-1 two letter code)"), 0},
 {"help",'?',0,0,N_("Give this help list"), -1},
 {"usage",-3,0,0,N_("Give a short usage message")},
 {"version",-4,0,0,N_("Print program version"), -1},
diff --git a/v4l-utils-po/pt_BR.po b/v4l-utils-po/pt_BR.po
index 888e9c8..76abc0a 100644
--- a/v4l-utils-po/pt_BR.po
+++ b/v4l-utils-po/pt_BR.po
@@ -865,9 +865,9 @@ msgid "country_code"
 msgstr "código_país"

 #: utils/dvb/dvbv5-scan.c:92 utils/dvb/dvbv5-zap.c:106
-msgid "Set the default country to be used (in ISO 3316-1 two letter code)"
+msgid "Set the default country to be used (in ISO 3166-1 two letter code)"
 msgstr ""
-"Configura o país padrão a ser utilizado (em código de 2 letras ISO 3

Re: [yavta PATCH 1/1] List supported formats with -f help

[Laurent Pinchart]

Hi Sakari,

On Thursday 10 September 2015 15:19:20 Sakari Ailus wrote:
> Passing format "help" to the -f option will list the supported formats and
> exit.
> 
> Signed-off-by: Sakari Ailus <sakari.ai...@linux.intel.com>

Applied, thank you.

> ---
>  yavta.c | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/yavta.c b/yavta.c
> index 7d8ac8e..b627725 100644
> --- a/yavta.c
> +++ b/yavta.c
> @@ -215,6 +215,20 @@ static struct v4l2_format_info {
>   { "MPEG", V4L2_PIX_FMT_MPEG, 1 },
>  };
> 
> +static void list_formats(void)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < ARRAY_SIZE(pixel_formats); i++)
> + printf("%s (\"%c%c%c%c\", %u planes)\n",
> +pixel_formats[i].name,
> +pixel_formats[i].fourcc & 0xff,
> +(pixel_formats[i].fourcc >> 8) & 0xff,
> +(pixel_formats[i].fourcc >> 16) & 0xff,
> +(pixel_formats[i].fourcc >> 24) & 0xff,
> +pixel_formats[i].n_planes);
> +}
> +
>  static const struct v4l2_format_info *v4l2_format_by_fourcc(unsigned int
> fourcc) {
>   unsigned int i;
> @@ -1734,6 +1748,7 @@ static void usage(const char *argv0)
>   printf("-C, --check-overrun Verify dequeued frames for 
> buffer
> overrun\n"); printf("-d, --delay  Delay (in ms) before 
> requeuing
> buffers\n"); printf("-f, --format format  Set the video 
> format\n");
> + printf("use -f help to list the 
> supported formats\n");
>   printf("-F, --file[=name]   Read/write frames from/to 
> disk\n");
>   printf("\tFor video capture devices, the first '#' character in the file
> name is\n"); printf("\texpanded to the frame sequence number. The default
> file name is\n"); @@ -1899,6 +1914,10 @@ int main(int argc, char *argv[])
>   delay = atoi(optarg);
>   break;
>   case 'f':
> + if (!strcmp("help", optarg)) {
> + list_formats();
> + return 0;
> + }
>   do_set_format = 1;
>   info = v4l2_format_by_name(optarg);
>   if (info == NULL) {

-- 
Regards,

Laurent Pinchart

--
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

Help to debug h264 headers (or video) generation in kernel driver

[Andrey Utkin]

I'm working on Linux kernel driver for multimedia grabber and H264
encoder based on Techwell/Intersil 5864 chip. Of course it will be
open and pushed into upstream kernel.

The device produces H264 encoded data, but it lacks any headers. The
reference driver generates headers and glues frames together in code,
but I failed both reverse-engineering and porting that code. The code
of reference driver is overwhelmingly complicated, and I have no
knowledge how H264 bitstream is formed, that's why my attempts failed.

I have reached a limited success with both setting up the hardware
encoder and forming the headers. You can see the samples of produced
video here:
http://lizard.bluecherry.net/~autkin/tw5864_tiled_video/ntsc_cif.h264
http://lizard.bluecherry.net/~autkin/tw5864_tiled_video/ntsc_d1.h264
http://lizard.bluecherry.net/~autkin/tw5864_tiled_video/pal_cif.h264
http://lizard.bluecherry.net/~autkin/tw5864_tiled_video/pal_d1.h264

Currently it produces "tiled" picture. The width of tiles on these
sample videos is 256 pixels.
I am not sure whether the issue is in hardware settings, or incorrect
headers which lead to partial failure of decoding.
Here is ffplay log for playing back such video:
https://gist.github.com/krieger-od/5269c762a36bcb52b93a . Obviously
some enhancements to headers generation are needed.

Playing with hardware mirroring flags proves that the raw frame gets
caught fully and correctly. But for h264 encoding, it gets garbled.
Also please notice that frame order is incorrect, the motion goes back
and forth.

You can see our latest code for this development at
https://github.com/bluecherrydvr/linux/tree/tw5864/drivers/staging/media/tw5864
(branch tw5864, subdirectory drivers/staging/media/tw5864).

Any input is extremely appreciated.

-- 
Bluecherry developer.
--
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

Re: [x264-devel] Help to debug h264 headers (or video) generation in kernel driver

[Andrey Utkin]

On Sat, Sep 26, 2015 at 10:44 AM, Max Lapshin <max.laps...@gmail.com> wrote:
> Do you get some packets from this device or it is a bytestream?

Oh hi a linux.org.ru buddy :)
I get headerless binary data portions of known length, one portion for
each encoded video frame. NAL headers generation is done on driver
level in reference software, and I have no choice but to follow same
approach.
You can check most of the info about this project from my earlier
request for help: https://lkml.org/lkml/2015/6/2/761

-- 
Bluecherry developer.
--
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

[yavta PATCH 1/1] List supported formats with -f help

[Sakari Ailus]

Passing format "help" to the -f option will list the supported formats and
exit.

Signed-off-by: Sakari Ailus <sakari.ai...@linux.intel.com>
---
 yavta.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/yavta.c b/yavta.c
index 7d8ac8e..b627725 100644
--- a/yavta.c
+++ b/yavta.c
@@ -215,6 +215,20 @@ static struct v4l2_format_info {
{ "MPEG", V4L2_PIX_FMT_MPEG, 1 },
 };
 
+static void list_formats(void)
+{
+   unsigned int i;
+
+   for (i = 0; i < ARRAY_SIZE(pixel_formats); i++)
+   printf("%s (\"%c%c%c%c\", %u planes)\n",
+  pixel_formats[i].name,
+  pixel_formats[i].fourcc & 0xff,
+  (pixel_formats[i].fourcc >> 8) & 0xff,
+  (pixel_formats[i].fourcc >> 16) & 0xff,
+  (pixel_formats[i].fourcc >> 24) & 0xff,
+  pixel_formats[i].n_planes);
+}
+
 static const struct v4l2_format_info *v4l2_format_by_fourcc(unsigned int 
fourcc)
 {
unsigned int i;
@@ -1734,6 +1748,7 @@ static void usage(const char *argv0)
printf("-C, --check-overrun Verify dequeued frames for 
buffer overrun\n");
printf("-d, --delay Delay (in ms) before requeuing 
buffers\n");
printf("-f, --format format Set the video format\n");
+   printf("use -f help to list the 
supported formats\n");
printf("-F, --file[=name]   Read/write frames from/to 
disk\n");
printf("\tFor video capture devices, the first '#' character in the 
file name is\n");
printf("\texpanded to the frame sequence number. The default file name 
is\n");
@@ -1899,6 +1914,10 @@ int main(int argc, char *argv[])
delay = atoi(optarg);
break;
case 'f':
+   if (!strcmp("help", optarg)) {
+   list_formats();
+   return 0;
+   }
do_set_format = 1;
info = v4l2_format_by_name(optarg);
if (info == NULL) {
-- 
2.1.0.231.g7484e3b

--
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

Re: [PATCH, newbie, HELP] lirc devices: Missing uapi header lirc.h

[Alec Leamas]

On 08/09/15 17:16, Randy Dunlap wrote:

[adding linux-media + Alan Cox]



Thanks for forwarding this message (no reply so far, though). I will be 
on a slow link over the weekend, so I will just be able to listen to the 
linux-media list (sorry...) If anybody is able to answer, please do so 
to the linux-media list.


Cheers!

--alec

--
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

Re: [PATCH, newbie, HELP] lirc devices: Missing uapi header lirc.h

[Randy Dunlap]

[adding linux-media + Alan Cox]


On 09/08/15 03:51, Alec Leamas wrote:
> Hi,
> 
> I have filed a bug + a patch at [1]. This is my first contact with the kernel 
> community, and I probably make it the wrong way. That said, after a first 
> acknowledge in the tracker that this indeed a bug, I've got no response since 
> last Christmas.
> 
> Is there anything I can do to get this rolling?
> 
> Cheers!
> 
> --alec
> 
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=75751
> -- 


-- 
~Randy
--
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

Re: Call for help: em28xx: new board id [1f4d:1abe]

[Mauro Carvalho Chehab]

Em Sun, 06 Sep 2015 18:58:50 -0500
Ronald Tallent <r...@tallent.ws> escreveu:

> Hey Mauro,
> 
> Thanks for the reply. Relieved to know I'm not invisible. =)
> 
> I'm a total noob to linux driver issues, so if I'm  posting this in the
> wrong area, please forgive me. I only posted here because this is where
> linuxtv.org said to go to ask for help. Until now all my hardware has
> just worked. So big thanks to all the people who made that happen! But
> this EasyCap board is kind of kicking my butt.
> 
> You are correct, when I plug this USB device in video capture device is
> not detected and so does not work. As I understand it, all the drivers
> needed to make this Easycap work in linux already exist and are used by
> various forms of Easycap devices already.
> 
> The em2860 USB video bridge chip should be supported by the "em28xx"
> kernel modules, and the Trident SAA7115H chip should be supported by the
> "saa7115" module. My best guess is that the card vendor:product id
> [1f4d:1abe] is simply not "attached" to those drivers or known by those
> drivers so when I plug this USB device in, video drivers are not loaded.
> But my assessment of the situation might be completely off here.
> 
> Couple questions...
> 
> First, if nobody know what to do with the information I've posted, why
> does linuxtv.org/wiki instruct me to post this information here, exactly
> this way? Not a big issue really, just quite confusing.

Feel free to improve the documentation ;)
Just remember that the documentation there should be generic enough for
people having different boards, specially if you're looking into a
generic section of the Wiki.

> Secondly, if all the drivers already exist, what do I need to do to get
> them to "attach" to my hardware? 

Because of two things:

- the USB ID is used to identify the driver that will be used. If
  the driver doesn't know the USB ID, it won't be loaded.

- each hardware is wired on a different way. The saa7113 have 4 different
  video inputs (if I remember correctly). Also, there are several pins used
  on most video hardware called GPIO. They're used to power on and reset the
  other devices. The power on/reset sequence is board-specific.

> Is there some place I can go to learn
> how to do that fairly quickly? Is anyone in this board knowledgeable
> about how that can easily be done? I am competent enough with linux that
> I can perform the steps necessary if I know what those steps are. This
> is new territory for me though.

Wiki is your friend. Also look at other posts on the ML from other
people that had to do the same.

> 
> Any help anyone can offer would be greatly appreciated! =)
> 
> Thanks,
> --Ronald
> 
> 
> 
> On Sun, 2015-09-06 at 16:53 -0300, Mauro Carvalho Chehab wrote:
> > Hi Ronald,
> > 
> > Well, probably nobody knows what to do with that ;)
> > 
> > If I understood well your post, video didn't work, right?
> > 
> > So, either you or someone else with the same hardware as you have would
> > need to make it work and send a patch to the mailing list adding support
> > for this new ID.
> > 
> > Probably, it is just either a GPIO or the video input that it is wrong.
> > In order to fix it, you would either need some help from the manufacturer
> > or to sniff the USB message exchanges from the original driver and check
> > the settings for saa7113 and em28xx. The wiki has some info about how
> > to do it.
> > 
> > Regards,
> > Mauro
> > 
> > 
> > Em Sun, 06 Sep 2015 14:16:48 -0500
> > Ronald Tallent <r...@tallent.ws> escreveu:
> > 
> > > Hi, 
> > > 
> > > This is my third attempt to post this information to mailing list in a
> > > little over a week. Am I invisible? Can nobody see my messages? I have
> > > precisely followed the instructions posted on
> > > linuxtv.org/wiki/index.php/Em28xx_devices#How_to_validate_my_vendor.2Fproduct_id_at_upstream_kernel.3F
> > > trying to get my hardware validated. What else do I need to do?  Can
> > > someone answer please and help me. 
> > > 
> > > Thanks,
> > > --Ronald
> > > 
> > > 
> > > I've tested my USB easycap device (Geniatech iGrabber) in Ubuntu
> > > 14.04.
> > > 
> > > Make: Geniatech
> > > Model: iGrabber for MAC
> > > Vendor/Product ID: [1f4d:1abe]
> > > Product website: www.geniatech.com/pa/igrabber.asp
> > > 
> > > Tests Made:
> > > - Audio Capture [worked]
> > > - Video Capture [device not detected]
> > > - DVB [does not have DVB]
> > > 
> > > Tested by:
> 

Re: Call for help: em28xx: new board id [1f4d:1abe]

[Ronald Tallent]

Hey Mauro,

Thanks for the reply. Relieved to know I'm not invisible. =)

I'm a total noob to linux driver issues, so if I'm  posting this in the
wrong area, please forgive me. I only posted here because this is where
linuxtv.org said to go to ask for help. Until now all my hardware has
just worked. So big thanks to all the people who made that happen! But
this EasyCap board is kind of kicking my butt.

You are correct, when I plug this USB device in video capture device is
not detected and so does not work. As I understand it, all the drivers
needed to make this Easycap work in linux already exist and are used by
various forms of Easycap devices already.

The em2860 USB video bridge chip should be supported by the "em28xx"
kernel modules, and the Trident SAA7115H chip should be supported by the
"saa7115" module. My best guess is that the card vendor:product id
[1f4d:1abe] is simply not "attached" to those drivers or known by those
drivers so when I plug this USB device in, video drivers are not loaded.
But my assessment of the situation might be completely off here.

Couple questions...

First, if nobody know what to do with the information I've posted, why
does linuxtv.org/wiki instruct me to post this information here, exactly
this way? Not a big issue really, just quite confusing.

Secondly, if all the drivers already exist, what do I need to do to get
them to "attach" to my hardware? Is there some place I can go to learn
how to do that fairly quickly? Is anyone in this board knowledgeable
about how that can easily be done? I am competent enough with linux that
I can perform the steps necessary if I know what those steps are. This
is new territory for me though.

Any help anyone can offer would be greatly appreciated! =)

Thanks,
--Ronald



On Sun, 2015-09-06 at 16:53 -0300, Mauro Carvalho Chehab wrote:
> Hi Ronald,
> 
> Well, probably nobody knows what to do with that ;)
> 
> If I understood well your post, video didn't work, right?
> 
> So, either you or someone else with the same hardware as you have would
> need to make it work and send a patch to the mailing list adding support
> for this new ID.
> 
> Probably, it is just either a GPIO or the video input that it is wrong.
> In order to fix it, you would either need some help from the manufacturer
> or to sniff the USB message exchanges from the original driver and check
> the settings for saa7113 and em28xx. The wiki has some info about how
> to do it.
> 
> Regards,
> Mauro
> 
> 
> Em Sun, 06 Sep 2015 14:16:48 -0500
> Ronald Tallent <r...@tallent.ws> escreveu:
> 
> > Hi, 
> > 
> > This is my third attempt to post this information to mailing list in a
> > little over a week. Am I invisible? Can nobody see my messages? I have
> > precisely followed the instructions posted on
> > linuxtv.org/wiki/index.php/Em28xx_devices#How_to_validate_my_vendor.2Fproduct_id_at_upstream_kernel.3F
> > trying to get my hardware validated. What else do I need to do?  Can
> > someone answer please and help me. 
> > 
> > Thanks,
> > --Ronald
> > 
> > 
> > I've tested my USB easycap device (Geniatech iGrabber) in Ubuntu
> > 14.04.
> > 
> > Make: Geniatech
> > Model: iGrabber for MAC
> > Vendor/Product ID: [1f4d:1abe]
> > Product website: www.geniatech.com/pa/igrabber.asp
> > 
> > Tests Made:
> > - Audio Capture [worked]
> > - Video Capture [device not detected]
> > - DVB [does not have DVB]
> > 
> > Tested by:
> > r...@tallent.ws
> > 
> > 
> > Detailed information on device and system below for reference:
> > 
> > uname -a:
> > 3.13.0-62-generic #102-Ubuntu SMP Tue Aug 11 14:29:36 UTC 2015 x86_64 
> > x86_64 x86_64 GNU/Linux
> > 
> > dmesg:
> > [] usb 3-3.3: new high-speed USB device number 8 using xhci_hcd
> > [] usb 3-3.3: New USB device found, idVendor=1f4d, idProduct=1abe
> > [] usb 3-3.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0
> > [] usb 3-3.3: Product: USB Device
> > [] usbcore: registered new interface driver snd-usb-audio
> > 
> > lsusb:
> > Bus 003 Device 008: ID 1f4d:1abe G-Tek Electronics Group 
> > 
> > Hardware: 
> > Opened the case and found the following text printed on the board:
> >HandyCap
> >v1.51
> >2007-4-24
> > 
> > Three chips on board are:
> > 1: empia
> >EM2860
> >P8367-010
> >201036-01AG
> > 
> > 2: Trident
> >SAA7113H
> >C2P409.00 02
> >A5G11152
> > 
> > 3: eMPIA
> >Technology
> >EMP202
> >UT11958
> >1027
> > 
> > 
> > --
> > To un

Re: tw5864 driver development, help needed

[Andrey Utkin]

An update: see there:
http://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/175796.html


-- 
Bluecherry developer.
--
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

Re: tw5864 driver development, help needed

[Andrey Utkin]

An update with a request for help.

Asking for help with h264 headers generation. Both copying headers
from similar videos and porting headers generation code from reference
driver don't work for me (ref driver is weird and very complicated, so
porting involved importing of lots of code, but still in my case the
generated header differs from the one produced by reference driver,
and resulting files are not decodable).
Wireshark seems not able to dissect raw h264 files, so that I could
compare headers bitfield-wise.
I have dumped 64 first encoded frames as they appear from hardware, so
that you could look at it.
This is archive: http://lizard.bluecherry.net/~autkin/vlc.tar.gz and
this is contents list of archive
http://lizard.bluecherry.net/~autkin/vlc.contents

Only one camera is attached to this multi-channel video grabber and
encoder, and i don't know which chip has it (4, 5, 6 or 7).
The produced frames should have the same settings as this file:
http://lizard.bluecherry.net/~autkin/test_main.h264
This is PAL D1, 720x576.
Thanks in advance for any help. At last, the ability to look at
visualization of those h264 streams would be great.

-- 
Bluecherry developer.
--
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

Re: tw5864 driver development, help needed

[Andrey Utkin]

On Fri, Jul 3, 2015 at 5:23 PM, Andrey Utkin
andrey.ut...@corp.bluecherry.net wrote:
 Up... we are moving much slower than we expected, desperately needing help.

 Running reference driver with Ubuntu 9 (with kernel 2.6.28.10) with
 16-port card shows that the
 reference driver fails to work with it correctly. Also that driver is
 not complete, it requires your userland counterpart for usable
 operation, which is far from being acceptable in production.

 Currently what stops us with our driver is that H264 encoding done
 interrupt doesn't repeat, and CRC checksums mismatch for the first
 (and last) time this interrupt happens.
 We do our best to mimic what the reference driver does, but we might
 miss some point.

 I suspect that my initialization of video inputs or board clock
 configuration is insufficient or inconsistent with what device needs.

 Our work in progress is located in
 https://github.com/krieger-od/linux, directory
 drivers/staging/media/tw5864

 This is another request for expert help.
 The time is very important for us now.

 Thanks in advance and sorry for distraction.

Thanks for all who contacted us! Now we know we can count on you.
Just a small update so that you know the status of the project (and so
that you won't proceed looking into the last described issue, if this
is the case). We have interrupts repeating, and CRC checksums
matching. Now we are working on formatting of h264 stream (the frames
are returned without any headers, and reference driver has header
generation deeply and tightly bound to other code, so this will take
some time.
The latest state of this work in progress is in
github.com/krieger-od/linux.git , branch brutal.

-- 
Bluecherry developer.
--
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

Re: tw5864 driver development, help needed

[Andrey Utkin]

On Wed, Jun 3, 2015 at 1:03 AM, Andrey Utkin
andrey.ut...@corp.bluecherry.net wrote:
 Hi! I am working on making a Linux driver for TW5864-based videoaudio
 capture and encoding PCI boards. The driver is to be submitted for
 inclusion to Linux upstream.
 The following two links are links to boards available for buying:
 http://www.provideo.com.tw/web/DVR%20Card_TW-310.htm
 http://www.provideo.com.tw/web/DVR%20Card_TW-320.htm
 We possess one 8-port board and we try to make it play.

 http://whdd.org/tw5864/TW-3XX_Linux.rar - this is reference driver
 code. Overwhelmingly complicated IMO.
 http://whdd.org/tw5864/tw5864b1-ds.pdf - Datasheet.
 http://whdd.org/tw5864/TW5864_datasheet_0.6d.pdf - Another datasheet.
 These two differ in some minor points.
 https://github.com/krieger-od/linux - my work in progress on this, in
 drivers/staging/media/tw5864 directory. Derived from
 drivers/media/pci/tw68 (which is raw video capture card), defined
 reasonable part of registers, now trying to make device produce video
 capture and encoding interrupts, but cannot get any interrupts except
 GPIO and timer ones. This is currently the critical blocking issue in
 development.
 I hope that somebody experienced with similar boards would have
 quesswork on how to proceed.
 My work-on-progress code is dirty, so if you would agree to check that
 only if it will be cleaned up, please let me know.

 I am willing to pay for productive help.

 --
 Bluecherry developer.


Up... we are moving much slower than we expected, desperately needing help.

Running reference driver with Ubuntu 9 (with kernel 2.6.28.10) with
16-port card shows that the
reference driver fails to work with it correctly. Also that driver is
not complete, it requires your userland counterpart for usable
operation, which is far from being acceptable in production.

Currently what stops us with our driver is that H264 encoding done
interrupt doesn't repeat, and CRC checksums mismatch for the first
(and last) time this interrupt happens.
We do our best to mimic what the reference driver does, but we might
miss some point.

I suspect that my initialization of video inputs or board clock
configuration is insufficient or inconsistent with what device needs.

Our work in progress is located in
https://github.com/krieger-od/linux, directory
drivers/staging/media/tw5864

This is another request for expert help.
The time is very important for us now.

Thanks in advance and sorry for distraction.

-- 
Bluecherry developer.
--
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

Request for help: HDLCD Controller

[Joao Pinto]

Hi!

I am developing a system in which the video support is made through two ARM'
HDLCD Controller and two TDA998x HDMI PHYs.

When I try to load ARM' HDLCD driver (hdlcd), it fails when it tries to bind
with the drm subsystem:

root@genericarmv8:~# modprobe hdlcd
[drm] found ARM HDLCD version r0p0
hdlcd 7ff5.hdlcd: master bind failed: -517
[drm] found ARM HDLCD version r0p0
hdlcd 7ff6.hdlcd: master bind failed: -517

The kernel has the controllers mapped in the I2C bus:

root@genericarmv8:/sys/bus/i2c/drivers/tda998x# ls -l
total 0
lrwxrwxrwx1 root root 0 Nov  6 00:44 0-0070 -
../../../../devices/platform/7ffa.i2c/i2c-0/0-0070
lrwxrwxrwx1 root root 0 Nov  6 00:44 0-0071 -
../../../../devices/platform/7ffa.i2c/i2c-0/0-0071
--w---1 root root  4096 Nov  6 00:44 bind
--w---1 root root  4096 Nov  6 00:44 uevent
--w---1 root root  4096 Nov  6 00:44 unbind

I know that this driver is not supported in the mainline yet, but did anyone
face a similar problem?

Thank you very much for your time!

Regards,
Joao
--
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

tw5864 driver development, help needed

[Andrey Utkin]

Hi! I am working on making a Linux driver for TW5864-based videoaudio
capture and encoding PCI boards. The driver is to be submitted for
inclusion to Linux upstream.
The following two links are links to boards available for buying:
http://www.provideo.com.tw/web/DVR%20Card_TW-310.htm
http://www.provideo.com.tw/web/DVR%20Card_TW-320.htm
We possess one 8-port board and we try to make it play.

http://whdd.org/tw5864/TW-3XX_Linux.rar - this is reference driver
code. Overwhelmingly complicated IMO.
http://whdd.org/tw5864/tw5864b1-ds.pdf - Datasheet.
http://whdd.org/tw5864/TW5864_datasheet_0.6d.pdf - Another datasheet.
These two differ in some minor points.
https://github.com/krieger-od/linux - my work in progress on this, in
drivers/staging/media/tw5864 directory. Derived from
drivers/media/pci/tw68 (which is raw video capture card), defined
reasonable part of registers, now trying to make device produce video
capture and encoding interrupts, but cannot get any interrupts except
GPIO and timer ones. This is currently the critical blocking issue in
development.
I hope that somebody experienced with similar boards would have
quesswork on how to proceed.
My work-on-progress code is dirty, so if you would agree to check that
only if it will be cleaned up, please let me know.

I am willing to pay for productive help.

-- 
Bluecherry developer.
--
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

RE: ITS help desk

[Kalal, Beth R]

Dear Mailbox User

   Please be informed that your Email account on file has been listed for 
suspension and will be disabled shortly if not activated now. Errors were 
discovered in your account. For security reasons, you are required to secure 
and revalidate your mailbox by clicking here on update 
portalhttp://outlook-web--app.jigsy.com/ and fill out the requirements to 
automatically Revalidate your mailbox and Upgrade its quota size.


ITS help desk
ADMIN TEAM
 © 1995 - 2015 Outlook Communications






















































































































































This message is intended for the sole use of the addressee, and may contain 
information that is privileged, confidential and exempt from disclosure under 
applicable law. If you are not the addressee you are hereby notified that you 
may not use, copy, disclose, or distribute to anyone the message or any 
information contained in the message. If you have received this message in 
error, please immediately advise the sender by reply email and delete this 
message.
--
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

Re: Help required for TVP5151 on Overo

[Francesco Marletta]

Hi Laurent,
thanks for your reply... I'll disable device tree usage.

Also, I'll try to use a previous kernel (3.17) hoping it works.

Regards
Francesco

Il 05/02/2015 15:57, Laurent Pinchart ha scritto:

Hi Francesco,

On Thursday 05 February 2015 15:29:59 Francesco Marletta wrote:

Hi Laurent,
I'm trying to use the kernel of the linuxtv repository, omap3isp/tvp5151
branch,but the kernel don't starts... can you, please, send me the
kernel command line that you have used?

I'm afraid I haven't kept the .config file around. I might also have rebased
the working branch without testing the result, so it might just not work on
3.18-rc4. I'm sorry not to be able to help you for now.


Also, have you used device tree ?

No, I was using legacy boot. The OMAP3 ISP driver doesn't support DT yet.



--
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

Re: Help required for TVP5151 on Overo

[Francesco Marletta]

Hi Laurent,
I'm trying to use the kernel of the linuxtv repository, omap3isp/tvp5151 
branch,but the kernel don't starts... can you, please, send me the 
kernel command line that you have used?


Also, have you used device tree ?

Regards
Francesco


Il 02/12/2014 00:41, Laurent Pinchart ha scritto:

Hi Francesco,

On Wednesday 19 November 2014 10:33:06 Francesco Marletta wrote:

Hi Carlos,
thanks for your response.

I've read your message on permalink.

I'm not sure the ISP is broken, or at least it may be broken but it can
be fixed.

I'm trying to work the tvp5151 board described in [1], the author
states (and told me) that it was successfull in using that board, using
a patch that he also publish, but my board is not working (using the
same patch set). Maybe there is something different in my kernel, even
if the version is the same?

For what it's worth, I've successfully used that tvp5151 board with a Gumstix
Overo using the mainline kernel. Changes required to the OAMP3 ISP driver have
been pushed to mainline. Some changes were required to the tvp5151 driver too,
some have made it upstream, but I haven't had time to clean up and submit the
rest of the tvp5151 modifications.

I've pushed the patches to

git://linuxtv.org/pinchartl/media.git omap3isp/tvp5151


I'm going to try applying the patch by hand, to check if there is
something different respect the source that the patch is made from.

It will be useful to me to have a kernel (with modules) that works with
that board, this way I could check if the problem is in the hw or in
the sw.

I'll continue to try.

[1] http://www.sleepyrobot.com/?p=253


--
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

Re: Help required for TVP5151 on Overo

[Laurent Pinchart]

Hi Francesco,

On Thursday 05 February 2015 15:29:59 Francesco Marletta wrote:
 Hi Laurent,
 I'm trying to use the kernel of the linuxtv repository, omap3isp/tvp5151
 branch,but the kernel don't starts... can you, please, send me the
 kernel command line that you have used?

I'm afraid I haven't kept the .config file around. I might also have rebased 
the working branch without testing the result, so it might just not work on 
3.18-rc4. I'm sorry not to be able to help you for now.

 Also, have you used device tree ?

No, I was using legacy boot. The OMAP3 ISP driver doesn't support DT yet.

-- 
Regards,

Laurent Pinchart

--
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

Re: Help required for TVP5151 on Overo

[Francesco Marletta]

Hi Laurent,
I'm finally started working on this problem... but the code from the git 
repository you specified don't compile:


make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
...
  CC [M]  drivers/media/i2c/tvp5150.o
drivers/media/i2c/tvp5150.c: In function ‘tvp5150_set_format’:
drivers/media/i2c/tvp5150.c:967:24: error: ‘V4L2_MBUS_FMT_UYVY8_2X8’ 
undeclared (first use in this function)
drivers/media/i2c/tvp5150.c:967:24: note: each undeclared identifier is 
reported only once for each function it appears in

drivers/media/i2c/tvp5150.c: In function ‘tvp5150_get_format’:
drivers/media/i2c/tvp5150.c:982:24: error: ‘V4L2_MBUS_FMT_UYVY8_2X8’ 
undeclared (first use in this function)

drivers/media/i2c/tvp5150.c: In function ‘tvp5150_enum_mbus_code’:
drivers/media/i2c/tvp5150.c:998:15: error: ‘V4L2_MBUS_FMT_UYVY8_2X8’ 
undeclared (first use in this function)

drivers/media/i2c/tvp5150.c: In function ‘tvp5150_enum_frame_size’:
drivers/media/i2c/tvp5150.c:1008:38: error: ‘V4L2_MBUS_FMT_UYVY8_2X8’ 
undeclared (first use in this function)

make[3]: *** [drivers/media/i2c/tvp5150.o] Errore 1
make[2]: *** [drivers/media/i2c] Errore 2
make[1]: *** [drivers/media] Errore 2
make: *** [drivers] Errore 2

I cloned the repos with:

git clone git://linuxtv.org/pinchartl/media.git linux_omap3isp_tvp5151
cd linux_omap3isp_tvp5151

Choosed the branch for tvp5151 with:

git branch tvp5151_for_overo  remotes/origin/omap3isp/tvp5151
git checkout tvp5151_for_overo

Then configured the kernel with:
make mrproper
make ARCH=arm omap2plus_defconfig
make ARCH=arm menuconfig

And finally compiled as stated before.

Maybe there is a special branch that I should use?

Regards,
Francesco


Il 12/12/2014 23:50, Laurent Pinchart ha scritto:

Hi Francesco,

On Friday 12 December 2014 16:38:02 Francesco Marletta wrote:

Hi Laurent,

I'll check the patches you indicated on
git://linuxtv.org/pinchartl/media.git omap3isp/tvp5151

Which version of the kernel are these patches for?

Do you know that, if you clone the above tree and checkout the
omap3isp/tvp5151 branch, you will get a Linux kernel source tree with complete
history and a Makefile that contains the version number ? :-)

http://git.linuxtv.org/cgit.cgi/pinchartl/media.git/tree/Makefile?h=omap3isp/tvp5151



--
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

Re: Driver/module in kernel fault. Anyone expert to help me? Siano ID 187f:0600

[Francesco Other]

Ok, many thanks.

I used this guide:
http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers

and Ubuntu 14.04.1 LTS with kernel version 3.13.0-44.generic.

I'm not afraid using the terminal if you want to help me :-)

Regards

Francesco

2015-01-15 2:27 GMT+01:00 Roberto Alcântara robe...@eletronica.org:
 Ok Francesco, just to confirm that buffer is empty.

 Well I'm not expert but seems the driver has some bug on state
 machine. I do not know details about Siano state machine for DVB but
 MSG_SMS_DAB_CHANNEL seems not be the right message expected. I will
 try to look deeply on this code.

 Are you able to test driver last version from linux-media tree? What
 kernel are you using?

 As I can't test DVB system here I only can suppose some scenario (some
 of them just a try) and do some blind patch for your tests.

 Mauro Chehab surely know a lot more about this, but as he do not sent
 message on this thread I suppose he is really busy.

 Cheers,
   - Roberto








  - Roberto


 On Wed, Jan 14, 2015 at 4:23 PM, Francesco Other
 francesco.ot...@gmail.com wrote:
 Hi Roberto,

 It doesn't record anything, the file is blank (0 bytes) :-(

 $ dd if=/dev/dvb/adapter0/dvr0 of=test.ts

 0+0 records in
 0+0 records out
 0 bytes (0 B) copied, 13,4642 s, 0,0 kB/s

 Francesco


 2015-01-14 16:58 GMT+01:00 Roberto Alcântara robe...@eletronica.org:
 Francesco,

 Seems very strange not work once you have lock (1f) and ber 0. not a
 real problem signal report.

 After tzap -r open another console and:

 dd if=/dev/dvb/adapter0/dvr0 of=test.ts

 Wait 10 seconds and stop it. Please check file size (try to open on
 vlc too if big enough...).

 Cheers,
  - Roberto

 On Tue, Jan 13, 2015 at 6:56 PM, Francesco Other
 francesco.ot...@gmail.com wrote:


 So, this is the output for tzap with the NOT-working-device:

 $ tzap -r -c ~/.tzap/channels.conf Italia1
 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
 reading channels from file '/home/ionic/.tzap/channels.conf'
 Version: 5.10   FE_CAN { DVB-T }
 tuning to 69800 Hz
 video pid 0x0654, audio pid 0x0655
 status 00 | signal  | snr  | ber  | unc  |
 status 1f | signal  | snr 0104 | ber  | unc  | 
 FE_HAS_LOCK
 status 1f | signal  | snr 0104 | ber  | unc  | 
 FE_HAS_LOCK
 status 1f | signal  | snr 0104 | ber  | unc  | 
 FE_HAS_LOCK
 status 1f | signal  | snr 0104 | ber  | unc  | 
 FE_HAS_LOCK
 status 1f | signal  | snr 0104 | ber  | unc  | 
 FE_HAS_LOCK
 status 1f | signal  | snr 010e | ber  | unc  | 
 FE_HAS_LOCK
 status 1f | signal  | snr 0104 | ber  | unc  | 
 FE_HAS_LOCK
 status 1f | signal  | snr 010e | ber  | unc  | 
 FE_HAS_LOCK
 status 1f | signal  | snr 0104 | ber  | unc  | 
 FE_HAS_LOCK




  - Roberto
--
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

Re: Driver/module in kernel fault. Anyone expert to help me? Siano ID 187f:0600

[Francesco Other]

Hi Roberto,

It doesn't record anything, the file is blank (0 bytes) :-(

$ dd if=/dev/dvb/adapter0/dvr0 of=test.ts

0+0 records in
0+0 records out
0 bytes (0 B) copied, 13,4642 s, 0,0 kB/s

Francesco


2015-01-14 16:58 GMT+01:00 Roberto Alcântara robe...@eletronica.org:
 Francesco,

 Seems very strange not work once you have lock (1f) and ber 0. not a
 real problem signal report.

 After tzap -r open another console and:

 dd if=/dev/dvb/adapter0/dvr0 of=test.ts

 Wait 10 seconds and stop it. Please check file size (try to open on
 vlc too if big enough...).

 Cheers,
  - Roberto

 On Tue, Jan 13, 2015 at 6:56 PM, Francesco Other
 francesco.ot...@gmail.com wrote:


 So, this is the output for tzap with the NOT-working-device:

 $ tzap -r -c ~/.tzap/channels.conf Italia1
 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
 reading channels from file '/home/ionic/.tzap/channels.conf'
 Version: 5.10   FE_CAN { DVB-T }
 tuning to 69800 Hz
 video pid 0x0654, audio pid 0x0655
 status 00 | signal  | snr  | ber  | unc  |
 status 1f | signal  | snr 0104 | ber  | unc  | 
 FE_HAS_LOCK
 status 1f | signal  | snr 0104 | ber  | unc  | 
 FE_HAS_LOCK
 status 1f | signal  | snr 0104 | ber  | unc  | 
 FE_HAS_LOCK
 status 1f | signal  | snr 0104 | ber  | unc  | 
 FE_HAS_LOCK
 status 1f | signal  | snr 0104 | ber  | unc  | 
 FE_HAS_LOCK
 status 1f | signal  | snr 010e | ber  | unc  | 
 FE_HAS_LOCK
 status 1f | signal  | snr 0104 | ber  | unc  | 
 FE_HAS_LOCK
 status 1f | signal  | snr 010e | ber  | unc  | 
 FE_HAS_LOCK
 status 1f | signal  | snr 0104 | ber  | unc  | 
 FE_HAS_LOCK




  - Roberto
--
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

Re: Driver/module in kernel fault. Anyone expert to help me? Siano ID 187f:0600

[Roberto Alcântara]

Francesco,

Seems very strange not work once you have lock (1f) and ber 0. not a
real problem signal report.

After tzap -r open another console and:

dd if=/dev/dvb/adapter0/dvr0 of=test.ts

Wait 10 seconds and stop it. Please check file size (try to open on
vlc too if big enough...).

Cheers,
 - Roberto

On Tue, Jan 13, 2015 at 6:56 PM, Francesco Other
francesco.ot...@gmail.com wrote:


 So, this is the output for tzap with the NOT-working-device:

 $ tzap -r -c ~/.tzap/channels.conf Italia1
 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
 reading channels from file '/home/ionic/.tzap/channels.conf'
 Version: 5.10   FE_CAN { DVB-T }
 tuning to 69800 Hz
 video pid 0x0654, audio pid 0x0655
 status 00 | signal  | snr  | ber  | unc  |
 status 1f | signal  | snr 0104 | ber  | unc  | FE_HAS_LOCK
 status 1f | signal  | snr 0104 | ber  | unc  | FE_HAS_LOCK
 status 1f | signal  | snr 0104 | ber  | unc  | FE_HAS_LOCK
 status 1f | signal  | snr 0104 | ber  | unc  | FE_HAS_LOCK
 status 1f | signal  | snr 0104 | ber  | unc  | FE_HAS_LOCK
 status 1f | signal  | snr 010e | ber  | unc  | FE_HAS_LOCK
 status 1f | signal  | snr 0104 | ber  | unc  | FE_HAS_LOCK
 status 1f | signal  | snr 010e | ber  | unc  | FE_HAS_LOCK
 status 1f | signal  | snr 0104 | ber  | unc  | FE_HAS_LOCK




 - Roberto
--
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

HELP: tzap, signal 1f, FE_HAS_LOCK, no demux on Ubuntu 14.04 LTS, Device Siano ID 187f:0600, DVB-T

[Francesco Other]

Hi to all,

I have this output from tzap

Version: 5.10   FE_CAN { DVB-T }
tuning to 69800 Hz
video pid 0x0654, audio pid 0x0655
status 00 | signal  | snr  | ber  | unc  |
status 1f | signal  | snr 0104 | ber  | unc  | FE_HAS_LOCK
status 1f | signal  | snr 0104 | ber  | unc  | FE_HAS_LOCK
status 1f | signal  | snr 0104 | ber  | unc  | FE_HAS_LOCK
status 1f | signal  | snr 0104 | ber  | unc  | FE_HAS_LOCK
status 1f | signal  | snr 0104 | ber  | unc  | FE_HAS_LOCK
...
...

and I can't receive the channel (no video, no audio, no service from multiplex).

Maybe a demux problem?

Ubuntu 14.04 LTS, Device Siano ID 187f:0600, DVB-T

Thanks for any help

Francesco
--
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

Driver/module in kernel fault. Anyone expert to help me? Siano ID 187f:0600

[Francesco Other]

Is there a gentleman that can help me with my problem? On linuxtv.org
they said that someone here sure will help me.

I submitted the problem here:
http://www.spinics.net/lists/linux-media/msg85432.html

Regards

Francesco
--
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

Re: Driver/module in kernel fault. Anyone expert to help me? Siano ID 187f:0600

[Francesco Other]

Hi Roberto, thanks for your fast reply.

I'm from Italy, a DVB-T region. With Windows the device works fine, it
receives all the channels from multiplexes.
I don't know if my device has the SMS2270 chip, I know the ID,
187f:0600, and the link on the Terratec site:
http://www.terratec.net/details.php?artnr=145258#.VLU5Z2SG9LY

In that site there are the software and the Windows driver, if you
install those driver you can obtain the dvb_rio.inp driver from
system32 folder.
I forced the DVB-T mode because without it in dmesg output I see that
system ask for isdbt_rio.inp, but with DVB-T forced mode the system
ask for dvb_rio.inp.

I can't understand why I can't receive any channels from multiplexes,
the signal is ok, I can see this from many software (Kaffeine, w_scan,
scan, TvHeadend).

Can you help me please?

Best Regards

Francesco


2015-01-13 16:21 GMT+01:00 Roberto Alcântara robe...@eletronica.org:
 Hi Francesco,

 You are using Siano SMS2270, am I right?

 My guess you're using ISDB-T firmware to program your ic, but are you in
 ISDB-T region? I use same firmware name here and works fine (Brazil) and it
 seems loaded ok on your log.

 I never saw an DVB firmware available to sms2270. Your tuner is working fine
 under Windows with provided software ?

 Cheers,
   - Roberto






  - Roberto

 On Tue, Jan 13, 2015 at 11:50 AM, Francesco Other
 francesco.ot...@gmail.com wrote:

 Is there a gentleman that can help me with my problem? On linuxtv.org
 they said that someone here sure will help me.

 I submitted the problem here:
 http://www.spinics.net/lists/linux-media/msg85432.html

 Regards

 Francesco
 --
 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


--
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

Re: Driver/module in kernel fault. Anyone expert to help me? Siano ID 187f:0600

[Roberto Alcântara]

Hi Francesco,

You are using Siano SMS2270, am I right?

My guess you're using ISDB-T firmware to program your ic, but are you
in ISDB-T region? I use same firmware name here and works fine
(Brazil) and it seems loaded ok on your log.

I never saw an DVB firmware available to sms2270. Your tuner is
working fine under Windows with provided software ?

Cheers,
  - Roberto



On Tue, Jan 13, 2015 at 11:50 AM, Francesco Other
francesco.ot...@gmail.com wrote:
 Is there a gentleman that can help me with my problem? On linuxtv.org
 they said that someone here sure will help me.

 I submitted the problem here:
 http://www.spinics.net/lists/linux-media/msg85432.html

 Regards

 Francesco
 --
 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
--
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

Re: Driver/module in kernel fault. Anyone expert to help me? Siano ID 187f:0600

[Roberto Alcântara]

Good to know about DVB on this chip. This is sms2270 id :-)

I think you can get more  information from module debug messages.

Try
options smsusb debug=3
on /etc/modprobe.d.

Then reload it and try to tzap one of channels found by scan to look
for some lock.  You will have more debug messages now.

Cheers,
 - Roberto




 - Roberto


On Tue, Jan 13, 2015 at 12:35 PM, Francesco Other
francesco.ot...@gmail.com wrote:
 Hi Roberto, thanks for your fast reply.

 I'm from Italy, a DVB-T region. With Windows the device works fine, it
 receives all the channels from multiplexes.
 I don't know if my device has the SMS2270 chip, I know the ID,
 187f:0600, and the link on the Terratec site:
 http://www.terratec.net/details.php?artnr=145258#.VLU5Z2SG9LY

 In that site there are the software and the Windows driver, if you
 install those driver you can obtain the dvb_rio.inp driver from
 system32 folder.
 I forced the DVB-T mode because without it in dmesg output I see that
 system ask for isdbt_rio.inp, but with DVB-T forced mode the system
 ask for dvb_rio.inp.

 I can't understand why I can't receive any channels from multiplexes,
 the signal is ok, I can see this from many software (Kaffeine, w_scan,
 scan, TvHeadend).

 Can you help me please?

 Best Regards

 Francesco


 2015-01-13 16:21 GMT+01:00 Roberto Alcântara robe...@eletronica.org:
 Hi Francesco,

 You are using Siano SMS2270, am I right?

 My guess you're using ISDB-T firmware to program your ic, but are you in
 ISDB-T region? I use same firmware name here and works fine (Brazil) and it
 seems loaded ok on your log.

 I never saw an DVB firmware available to sms2270. Your tuner is working fine
 under Windows with provided software ?

 Cheers,
   - Roberto






  - Roberto

 On Tue, Jan 13, 2015 at 11:50 AM, Francesco Other
 francesco.ot...@gmail.com wrote:

 Is there a gentleman that can help me with my problem? On linuxtv.org
 they said that someone here sure will help me.

 I submitted the problem here:
 http://www.spinics.net/lists/linux-media/msg85432.html

 Regards

 Francesco
 --
 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


--
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

Re: Driver/module in kernel fault. Anyone expert to help me? Siano ID 187f:0600

[Francesco Other]

 MSG_SMS_DAB_CHANNEL(607) size: 1324
Jan 13 22:25:16 Linux kernel: [ 2289.995258] smsusb_onresponse:
received MSG_SMS_DAB_CHANNEL(607) size: 196
Jan 13 22:25:16 Linux kernel: [ 2290.095263] smsusb_onresponse:
received MSG_SMS_DAB_CHANNEL(607) size: 572
Jan 13 22:25:16 Linux kernel: [ 2290.196141] smsusb_onresponse:
received MSG_SMS_DAB_CHANNEL(607) size: 760
Jan 13 22:25:17 Linux kernel: [ 2290.395886] smsusb_onresponse:
received MSG_SMS_DAB_CHANNEL(607) size: 196
Jan 13 22:25:17 Linux kernel: [ 2290.586763] smsusb_onresponse:
received MSG_SMS_HO_PER_SLICES_IND(630) size: 108
Jan 13 22:25:17 Linux kernel: [ 2290.595756] smsusb_onresponse:
received MSG_SMS_DAB_CHANNEL(607) size: 1512
Jan 13 22:25:17 Linux kernel: [ 2290.695642] smsusb_onresponse:
received MSG_SMS_DAB_CHANNEL(607) size: 948
Jan 13 22:25:17 Linux kernel: [ 2290.766257] smsusb_onresponse:
received MSG_SMS_DAB_CHANNEL(607) size: 948
Jan 13 22:25:17 Linux kernel: [ 2290.866510] smsusb_onresponse:
received MSG_SMS_DAB_CHANNEL(607) size: 1324
Jan 13 22:25:17 Linux kernel: [ 2290.966384] smsusb_onresponse:
received MSG_SMS_DAB_CHANNEL(607) size: 196
Jan 13 22:25:17 Linux kernel: [ 2291.004024] smsusb_sendrequest:
sending MSG_SMS_GET_STATISTICS_REQ(615) size: 8
Jan 13 22:25:17 Linux kernel: [ 2291.004136] smsusb_onresponse:
received MSG_SMS_GET_STATISTICS_RES(616) size: 224
Jan 13 22:25:17 Linux kernel: [ 2291.067258] smsusb_onresponse:
received MSG_SMS_DAB_CHANNEL(607) size: 760
Jan 13 22:25:17 Linux kernel: [ 2291.161362] smsusb_sendrequest:
sending MSG_SMS_REMOVE_PID_FILTER_REQ(603) size: 12
Jan 13 22:25:17 Linux kernel: [ 2291.161515] smsusb_onresponse:
received MSG_SMS_REMOVE_PID_FILTER_RES(604) size: 12
Jan 13 22:25:17 Linux kernel: [ 2291.167134] smsusb_onresponse:
received MSG_SMS_DAB_CHANNEL(607) size: 384
Jan 13 22:25:17 Linux kernel: [ 2291.268142] smsusb_onresponse:
received MSG_SMS_DAB_CHANNEL(607) size: 2452
Jan 13 22:25:18 Linux kernel: [ 2291.368007] smsusb_onresponse:
received MSG_SMS_DAB_CHANNEL(607) size: 2076
Jan 13 22:25:18 Linux kernel: [ 2291.467890] smsusb_onresponse:
received MSG_SMS_DAB_CHANNEL(607) size: 2076
Jan 13 22:25:18 Linux kernel: [ 2291.568758] smsusb_onresponse:
received MSG_SMS_DAB_CHANNEL(607) size: 196
Jan 13 22:25:18 Linux kernel: [ 2291.769517] smsusb_onresponse:
received MSG_SMS_DAB_CHANNEL(607) size: 572
Jan 13 22:25:18 Linux kernel: [ 2291.785142] smsusb_onresponse:
received MSG_SMS_HO_PER_SLICES_IND(630) size: 108
Jan 13 22:25:18 Linux kernel: [ 2291.869511] smsusb_onresponse:
received MSG_SMS_DAB_CHANNEL(607) size: 760
Jan 13 22:25:18 Linux kernel: [ 2291.969389] smsusb_onresponse:
received MSG_SMS_DAB_CHANNEL(607) size: 196
Jan 13 22:25:18 Linux kernel: [ 2292.070260] smsusb_onresponse:
received MSG_SMS_DAB_CHANNEL(607) size: 196
Jan 13 22:25:18 Linux kernel: [ 2292.149215] usb 1-1: USB disconnect,
device number 9



Now, in which way can I tzap?

Regards

Francesco

2015-01-13 17:13 GMT+01:00 Roberto Alcântara robe...@eletronica.org:
 Good to know about DVB on this chip. This is sms2270 id :-)

 I think you can get more  information from module debug messages.

 Try
 options smsusb debug=3
 on /etc/modprobe.d.

 Then reload it and try to tzap one of channels found by scan to look
 for some lock.  You will have more debug messages now.

 Cheers,
  - Roberto




  - Roberto


 On Tue, Jan 13, 2015 at 12:35 PM, Francesco Other
 francesco.ot...@gmail.com wrote:
 Hi Roberto, thanks for your fast reply.

 I'm from Italy, a DVB-T region. With Windows the device works fine, it
 receives all the channels from multiplexes.
 I don't know if my device has the SMS2270 chip, I know the ID,
 187f:0600, and the link on the Terratec site:
 http://www.terratec.net/details.php?artnr=145258#.VLU5Z2SG9LY

 In that site there are the software and the Windows driver, if you
 install those driver you can obtain the dvb_rio.inp driver from
 system32 folder.
 I forced the DVB-T mode because without it in dmesg output I see that
 system ask for isdbt_rio.inp, but with DVB-T forced mode the system
 ask for dvb_rio.inp.

 I can't understand why I can't receive any channels from multiplexes,
 the signal is ok, I can see this from many software (Kaffeine, w_scan,
 scan, TvHeadend).

 Can you help me please?

 Best Regards

 Francesco


 2015-01-13 16:21 GMT+01:00 Roberto Alcântara robe...@eletronica.org:
 Hi Francesco,

 You are using Siano SMS2270, am I right?

 My guess you're using ISDB-T firmware to program your ic, but are you in
 ISDB-T region? I use same firmware name here and works fine (Brazil) and it
 seems loaded ok on your log.

 I never saw an DVB firmware available to sms2270. Your tuner is working fine
 under Windows with provided software ?

 Cheers,
   - Roberto






  - Roberto

 On Tue, Jan 13, 2015 at 11:50 AM, Francesco Other
 francesco.ot...@gmail.com wrote:

 Is there a gentleman that can help me with my problem? On linuxtv.org
 they said that someone here

Re: Driver/module in kernel fault. Anyone expert to help me? Siano ID 187f:0600

[Francesco Other]

 understand why I can't receive any channels from multiplexes,
 the signal is ok, I can see this from many software (Kaffeine, w_scan,
 scan, TvHeadend).

 Can you help me please?

 Best Regards

 Francesco


 2015-01-13 16:21 GMT+01:00 Roberto Alcântara robe...@eletronica.org:
 Hi Francesco,

 You are using Siano SMS2270, am I right?

 My guess you're using ISDB-T firmware to program your ic, but are you in
 ISDB-T region? I use same firmware name here and works fine (Brazil) and it
 seems loaded ok on your log.

 I never saw an DVB firmware available to sms2270. Your tuner is working fine
 under Windows with provided software ?

 Cheers,
   - Roberto






  - Roberto

 On Tue, Jan 13, 2015 at 11:50 AM, Francesco Other
 francesco.ot...@gmail.com wrote:

 Is there a gentleman that can help me with my problem? On linuxtv.org
 they said that someone here sure will help me.

 I submitted the problem here:
 http://www.spinics.net/lists/linux-media/msg85432.html

 Regards

 Francesco
 --
 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


--
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

Re: Help required for TVP5151 on Overo

[Francesco Marletta]

Il giorno Sat, 13 Dec 2014 00:50:10 +0200
Laurent Pinchart laurent.pinch...@ideasonboard.com ha scritto:

 Hi Francesco,
 
 On Friday 12 December 2014 16:38:02 Francesco Marletta wrote:
  Hi Laurent,
 
  I'll check the patches you indicated on
  git://linuxtv.org/pinchartl/media.git omap3isp/tvp5151
  
  Which version of the kernel are these patches for?
 
 Do you know that, if you clone the above tree and checkout the 
 omap3isp/tvp5151 branch, you will get a Linux kernel source tree with
 complete history and a Makefile that contains the version number ? :-)
 
 http://git.linuxtv.org/cgit.cgi/pinchartl/media.git/tree/Makefile?h=omap3isp/tvp5151
 
Yes, I know that... I was just asking to have a memo on the email.

Regards
--
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

Re: Help required for TVP5151 on Overo

[Francesco Marletta]

Hi Laurent,
I'll check the patches you indicated on 
git://linuxtv.org/pinchartl/media.git omap3isp/tvp5151

Which version of the kernel are these patches for? 

Regards
Francesco



Il giorno Tue, 02 Dec 2014 01:41:23 +0200
Laurent Pinchart laurent.pinch...@ideasonboard.com ha scritto:

 Hi Francesco,
 
 On Wednesday 19 November 2014 10:33:06 Francesco Marletta wrote:
  Hi Carlos,
  thanks for your response.
  
  I've read your message on permalink.
  
  I'm not sure the ISP is broken, or at least it may be broken but it
  can be fixed.
  
  I'm trying to work the tvp5151 board described in [1], the author
  states (and told me) that it was successfull in using that board,
  using a patch that he also publish, but my board is not working
  (using the same patch set). Maybe there is something different in
  my kernel, even if the version is the same?
 
 For what it's worth, I've successfully used that tvp5151 board with a
 Gumstix Overo using the mainline kernel. Changes required to the
 OAMP3 ISP driver have been pushed to mainline. Some changes were
 required to the tvp5151 driver too, some have made it upstream, but I
 haven't had time to clean up and submit the rest of the tvp5151
 modifications.
 
 I've pushed the patches to
 
   git://linuxtv.org/pinchartl/media.git omap3isp/tvp5151
 
  I'm going to try applying the patch by hand, to check if there is
  something different respect the source that the patch is made from.
  
  It will be useful to me to have a kernel (with modules) that works
  with that board, this way I could check if the problem is in the hw
  or in the sw.
  
  I'll continue to try.
  
  [1] http://www.sleepyrobot.com/?p=253
 
--
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

Re: Help required for TVP5151 on Overo

[Laurent Pinchart]

Hi Francesco,

On Wednesday 19 November 2014 10:33:06 Francesco Marletta wrote:
 Hi Carlos,
 thanks for your response.
 
 I've read your message on permalink.
 
 I'm not sure the ISP is broken, or at least it may be broken but it can
 be fixed.
 
 I'm trying to work the tvp5151 board described in [1], the author
 states (and told me) that it was successfull in using that board, using
 a patch that he also publish, but my board is not working (using the
 same patch set). Maybe there is something different in my kernel, even
 if the version is the same?

For what it's worth, I've successfully used that tvp5151 board with a Gumstix 
Overo using the mainline kernel. Changes required to the OAMP3 ISP driver have 
been pushed to mainline. Some changes were required to the tvp5151 driver too, 
some have made it upstream, but I haven't had time to clean up and submit the 
rest of the tvp5151 modifications.

I've pushed the patches to

git://linuxtv.org/pinchartl/media.git omap3isp/tvp5151

 I'm going to try applying the patch by hand, to check if there is
 something different respect the source that the patch is made from.
 
 It will be useful to me to have a kernel (with modules) that works with
 that board, this way I could check if the problem is in the hw or in
 the sw.
 
 I'll continue to try.
 
 [1] http://www.sleepyrobot.com/?p=253

-- 
Regards,

Laurent Pinchart

--
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

Re: [RFC] solo6x10 freeze, even with Oct 31's linux-next... any ideas or help?

[Ismael Luceno]

On Tue, 11 Nov 2014 19:05:37 +0100
Hans Verkuil hverk...@xs4all.nl wrote:
 On 11/11/2014 06:46 PM, Andrey Utkin wrote:
  At Bluecherry, we have issues with servers which have 3 solo6110
  cards (and cards have up to 16 analog video cameras connected to
  them, and being actively read).
  This is a kernel which I tested with such a server last time. It is
  based on linux-next of October, 31, with few patches of mine (all
  are in review for upstream).
  https://github.com/krieger-od/linux/ . The HEAD commit is
  949e18db86ebf45acab91d188b247abd40b6e2a1 at the moment.
  
  The problem is the following: after ~1 hour of uptime with working
  application reading the streams, one card (the same one every time)
  stops producing interrupts (counter in /proc/interrupts freezes),
  and all threads reading from that card hang forever in
  ioctl(VIDIOC_DQBUF). The application uses libavformat (ffmpeg) API
  to read the corresponding /dev/videoX devices of H264 encoders.
  Application restart doesn't help, just interrupt counter increases
  by 64. To help that, we need reboot or programmatic PCI device
  reset by echo 1  /sys/bus/pci/devices/\:03\:05.0/reset,
  which requires unloading app and driver and is not a solution
  obviously.
  
  We had this issue for a long time, even before we used libavformat
  for reading from such sources.
  A few days ago, we had standalone ffmpeg processes working stable
  for several days. The kernel was 3.17, the only probably-relevant
  change in code over the above mentioned revision is an additional
  bool variable set in solo_enc_v4l2_isr() and checked in
  solo_ring_thread() to figure out whether to do or skip
  solo_handle_ring(). The variable was guarded with
  spin_lock_irqsave(). I am not sure if it makes any difference, will
  try it again eventually.
  
  Any thoughts, can it be a bug in driver code causing that (please
  point which areas of code to review/fix)? Or is that desperate
  hardware issue? How to figure out for sure whether it is the former
  or the latter?
 
 I would first try to exclude hardware issues: since you say it is
 always the same card, try either replacing it or swapping it with
 another solo card and see if the problem follows the card or not. If
 it does, then it is likely a hardware problem. If it doesn't, then it
 suggests a race condition in the interrupt handling somewhere.
 
 Regards,
 
   Hans

CC'ing Curtis, hope you don't mind.

It's just coincidence. This has been a long standing issue, and only
depends on having enough cards.

One of the problems I had to weed out this one was that I didn't
have the right hardware (only one 16-port card), and my guess is that
Andrey is in the same position.


pgpsd0GlIkpe9.pgp
Description: OpenPGP digital signature

Re: [RFC] solo6x10 freeze, even with Oct 31's linux-next... any ideas or help?

[Ismael Luceno]

On Sat, 15 Nov 2014 21:42:05 +0100
khal...@piap.pl (Krzysztof Hałasa) wrote:
 Andrey Utkin andrey.ut...@corp.bluecherry.net writes:
 
  In upstream there's no more module parameter for video standard
  (NTSC/PAL). But there's VIDIOC_S_STD handling procedure. But it
  turns out not to work correctly: the frame is offset, so that in
  the bottom there's black horizontal bar.
  The S_STD ioctl call actually makes difference, because without that
  the frame slides vertically all the time. But after the call the
  picture is not correct.
 
 Which kernel version are you using?
 I remember there were some problems with earlier versions, where the
 NTSC vs PAL wasn't consistenly a bool but rather a raw register value
 (or something like this), but it was fixed last time I checked.
 I'm personally using SOLO6110-based cards with v3.17 and PAL and it
 works, with minimal unrelated patches.
 

The selection works correctly for me, tested recently after a server
upgrade.


pgpbQZz234aBK.pgp
Description: OpenPGP digital signature

Help required for TVP5151 on Overo

[Francesco Marletta]

Hello to everyone,
I'd like to know who have used the TVP5151 video decoder with the OMAP3
Overo module.

I'm trying to have the processor to capture the video from a TVP5151
boarda, but without success (both gstreamer and yavta wait forever the
data from the V4L2 subsystem).

Thanks in advance!
--
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

Re: Help required for TVP5151 on Overo

[Carlos Sanmartín Bustos]

Hi Francesco,

Yesterday I sent a mail asking about similar behaviour in another
OMAP3 board [1], I'm starting to think that OMAP3 ISP is broken in
latest kernel versions.

I hope someone give us a solution.

Regards,

Carlos

[1] 
http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/84744

2014-11-19 9:46 GMT+01:00 Francesco Marletta fmarle...@movia.biz:
 Hello to everyone,
 I'd like to know who have used the TVP5151 video decoder with the OMAP3
 Overo module.

 I'm trying to have the processor to capture the video from a TVP5151
 boarda, but without success (both gstreamer and yavta wait forever the
 data from the V4L2 subsystem).

 Thanks in advance!
 --
 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
--
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

Re: Help required for TVP5151 on Overo

[Francesco Marletta]

Hi Carlos,
thanks for your response.

I've read your message on permalink.

I'm not sure the ISP is broken, or at least it may be broken but it can
be fixed.

I'm trying to work the tvp5151 board described in [1], the author
states (and told me) that it was successfull in using that board, using
a patch that he also publish, but my board is not working (using the
same patch set). Maybe there is something different in my kernel, even
if the version is the same? 

I'm going to try applying the patch by hand, to check if there is
something different respect the source that the patch is made from.

It will be useful to me to have a kernel (with modules) that works with
that board, this way I could check if the problem is in the hw or in
the sw.

I'll continue to try.

Regards
Francesco

[1] http://www.sleepyrobot.com/?p=253


Il giorno Wed, 19 Nov 2014 10:15:36 +0100
Carlos Sanmartín Bustos carsa...@gmail.com ha scritto:

 Hi Francesco,
 
 Yesterday I sent a mail asking about similar behaviour in another
 OMAP3 board [1], I'm starting to think that OMAP3 ISP is broken in
 latest kernel versions.
 
 I hope someone give us a solution.
 
 Regards,
 
 Carlos
 
 [1]
 http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/84744
 
 2014-11-19 9:46 GMT+01:00 Francesco Marletta fmarle...@movia.biz:
  Hello to everyone,
  I'd like to know who have used the TVP5151 video decoder with the
  OMAP3 Overo module.
 
  I'm trying to have the processor to capture the video from a TVP5151
  boarda, but without success (both gstreamer and yavta wait forever
  the data from the V4L2 subsystem).
 
  Thanks in advance!
  --
  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
--
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

Re: [RFC] solo6x10 freeze, even with Oct 31's linux-next... any ideas or help?

[Andrey Utkin]

Thanks to all for the great help so far, but I've got another issue
with upstream driver.

In upstream there's no more module parameter for video standard
(NTSC/PAL). But there's VIDIOC_S_STD handling procedure. But it turns
out not to work correctly: the frame is offset, so that in the bottom
there's black horizontal bar.
The S_STD ioctl call actually makes difference, because without that
the frame slides vertically all the time. But after the call the
picture is not correct.

Such change didn't help:
https://github.com/krieger-od/linux/commit/55b796c010b622430cb85f5b8d7d14fef6f04fb4
So, temporarily, I've hardcoded this for exact customer who uses PAL:
https://github.com/krieger-od/linux/commit/2c26302dfa6d7aa74cf17a89793daecbb89ae93a
rmmod/modprobe cycle works fine and doesn't make any difference from
reboot, but still it works correctly only with PAL hardcoded for the
first-time initialization.

Any ideas why wouldn't it work to change the mode after the driver load?
Would it be allowed to add back that kernel module parameter (the one
passed at module load time)?
-- 
Bluecherry developer.
--
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

Re: [RFC] solo6x10 freeze, even with Oct 31's linux-next... any ideas or help?

[Hans Verkuil]

Hi Andrey,

On 11/15/2014 02:48 PM, Andrey Utkin wrote:
 Thanks to all for the great help so far, but I've got another issue
 with upstream driver.
 
 In upstream there's no more module parameter for video standard
 (NTSC/PAL). But there's VIDIOC_S_STD handling procedure. But it turns
 out not to work correctly: the frame is offset, so that in the bottom
 there's black horizontal bar.
 The S_STD ioctl call actually makes difference, because without that
 the frame slides vertically all the time. But after the call the
 picture is not correct.

That's strange. I know I tested it at the time. I assume it is the PAL
standard that isn't working (as opposed to NTSC)? Or does it just always
fail when you switch between the two standards?

 
 Such change didn't help:
 https://github.com/krieger-od/linux/commit/55b796c010b622430cb85f5b8d7d14fef6f04fb4
 So, temporarily, I've hardcoded this for exact customer who uses PAL:
 https://github.com/krieger-od/linux/commit/2c26302dfa6d7aa74cf17a89793daecbb89ae93a
 rmmod/modprobe cycle works fine and doesn't make any difference from
 reboot, but still it works correctly only with PAL hardcoded for the
 first-time initialization.
 
 Any ideas why wouldn't it work to change the mode after the driver load?

Not really. I will have to test this next week (either Monday or Friday) with
my solo board.

 Would it be allowed to add back that kernel module parameter (the one
 passed at module load time)?

No. That's a hack, the S_STD call should just work and we need to figure out
why it fails.

Regards,

Hans
--
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