the V4L mailing list is deprecated

[CityK]

Hello whomever at Redhat who is managing this list,

Its now been over two years since the Linux Media Mailing List was set 
up and it, indeed, has become well established  
(http://www.linuxtv.org/news.php?entry=2009-01-06.mchehab).   While most 
V4L-DVB community participants have transitioned over to the LMML, 
unfortunately, (likely from those unaware of the change) a fair number 
of user messages are still getting posted to the now essentially 
deprecated video4linux mailing list.  It is a diservice to those folks 
to continue allowing messages to make it on to the v4l list, as most of 
them will go unnoticed (as, as mentioned, most users in a position to 
respond to the sender have already abandoned this list in favour of the 
new LMML).


Could we please effectively wind down the video4linux by the end of this 
month  -- perhaps by way of setting up an auto notification response to 
any future submitter to the video4linux mailing list that their message 
should instead be sent to the LMML instead (perhaps even setting up a 
courtesy redirect of their message to the LMML for them) ?


Cheers

--
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: difference mchehab/new_build.git to media_build.git ?

[CityK]

vincent.mcintyre wrote:

Thanks for clarifying this. Doesn't this justify a one-line NEWS item?
I can understand not wanting to mention it while still experimental, but now...


Last night (well, actually the wee wee hours of this morning), I took 
the time to:
- add a news announcement regarding media_build on the front page of the 
wiki
- update the  
http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers 
article accordingly


I suspect that what has precluded any earlier case of a widely visible 
announcement being made, beyond those tidbits that have appeared on the 
mailing list, is a combination of:
- the necessity for having someone actually find and take time to 
perform such an administrative task

- and, amongst most, a case of general unfamiliarity  with the new system
- and, a question of maintainership of the new system and whether or not 
its status is still classified as experimental or has reached maturity
- and, access rights required to modify the Linuxtv proper website in 
regards to these developments


Speaking of time, I've now expended all of mine, and then some (as per 
usual), which I can devote to this matter.  Hopefully someone can take a 
look and correct any mistakes I've made or add any points I've 
overlooked on the wiki.   As well, hopefully someone else can take care 
of the other parts of the website that need to be updated.







--
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: ATSC Tuner in KWorld PC120-U PCI Hybrid ATSC (17de:a134)

[CityK]

I've been trying to get the ATSC tuner in my KWorld PC120-U PCI Hybrid
ATSC (17de:a134)


Are you sure you don't mean the PC120-U  ? --  I can't find such a 
product.   A PC150-U model, on the other hand



>  I see the drivers for both TDA18271HDC2 and TDA8290 loaded.
>  I thought TDA18271HDC2 was the digital channel decoder, isn't it? Is
>  the "digital channel decoder" different from the digital tuner??
>  Should be looking for a different chip?

they are detected by chip IDs.

The tda8290 is the IF demodulator for global analog TV.
In case of the saa7135 it is an extra chip on the PCB, which most often
can also control the tuner over an i2c gate.

The tda18271hdc2 is a global hybrid tuner for analog and digital
terrestrial TV. It can also provide a FM radio IF. Further processing
and stereo separation for that is done on capable bridges like
saa7133/35/31e, not on the tda 8290.

Yes, for any terrestrial digital TV you need an extra channel decoder
and all known details about it.

http://linuxtv.org/wiki/index.php/Category:ATSC_PCI_Cards

In case of terrestrial ATSC, it must be able to deal with 8VSB
modulation.


From the pics on newegg ( 
http://www.newegg.com/Product/Product.aspx?Item=N82E16815260032 ), it  
appears that they have used a Samsung demodulator

--
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: [Bulk] Re: v4l-dvb bug report

[CityK]

matteo sisti sette wrote:
> Yeah, thank you, I have found the FIREDTV=n trick on some other forum
> just a few minutes before I read your reply, and with that change it
> has compiled fine :)
>   
oops, I just sent my reply before I saw that you already figured it out

> I'm not sure what firedtv is but I don't think I need it :)
>   

its a driver for some firewire based DVB devices ... you won't need it.

> By the way may I ask a newbie question? If you need the kernel sources
> to compile v4l-dvb, it does not mean that you're recompiling the
> kernel, does it? :$

that's correct ... all you are doing is building the v4l-dvb drivers
against your specific kernel ...  after building them, you can then
install them, which effectively replaces the kernel supplied set of
v4l-dvb drivers with the set you just compiled/built
--
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: [Bulk] v4l-dvb bug report

[CityK]

Holy cow -- Ubuntu is still borked in regards to the firedtv stuff ?! 
What is that - something like 4 releases in a row now?

Anyway, well known problem, have a look here:
http://www.mail-archive.com/search?q=firedtv+Ubuntu&l=linux-media%40vger.kernel.org

first link will give you the easy fix to your compilation/build problem.
--
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: DNTV Dual Hybrid (7164) PCIe

[CityK]

Martin Brown wrote:
> I'm trying to get a driver working for this card under Ubuntu Lucid
> (10.04).
>
> I believe the card is based on the SAA7164 so I'm trying the
> kernellabs driver.
>
> Results of modprobe saa7164 are:
>
> /etc/modprobe.d/options.conf contains:
> options saa7164 card=4
>
>
> kernel: [ 159.091047] saa7164 driver loaded
> kernel: [ 159.091102] saa7164 :04:00.0: PCI INT A -> GSI 18
> (level, low) -> IRQ 18
> kernel: [ 159.091974] CORE saa7164[0]: subsystem: 107d:6f2c, board:
> Hauppauge WinTV-HVR2200 [card=4,insmod option]
> kernel: [ 159.091980] saa7164[0]/0: found at :04:00.0, rev: 129,
> irq: 18, latency: 0, mmio: 0x9300
> kernel: [ 159.135163] tveeprom 0-: Encountered bad packet header
> [00]. Corrupt or not a Hauppauge eeprom.
> kernel: [ 159.135168] saa7164[0]: Hauppauge eeprom: model=0
>
> That's it. Nothing more. No /dev/dvb/adpator... created.
>
> When /etc/modprobe.conf has:
> options saa7164 card=5 I get:
>
> kernel: [ 547.123384] saa7164 driver loaded
> kernel: [ 547.123435] saa7164 :04:00.0: PCI INT A -> GSI 18
> (level, low) -> IRQ 18
> kernel: [ 547.123614] CORE saa7164[0]: subsystem: 107d:6f2c, board:
> Hauppauge WinTV-HVR2200 [card=5,insmod option]
> kernel: [ 547.123619] saa7164[0]/0: found at :04:00.0, rev: 129,
> irq: 18, latency: 0, mmio: 0x9300
> kernel: [ 547.160228] tveeprom 0-: Encountered bad packet header
> [ff]. Corrupt or not a Hauppauge eeprom.
> kernel: [ 547.160233] saa7164[0]: Hauppauge eeprom: model=0
> kernel: [ 547.207655] tda18271 1-0060: creating new instance
> kernel: [ 547.211800] TDA18271HD/C2 detected @ 1-0060
> kernel: [ 547.469221] DVB: registering new adapter (saa7164)
> kernel: [ 547.469226] DVB: registering adapter 2 frontend 0 (NXP
> TDA10048HN DVB-T)...
>
> But only one /dev/dvb/adaptor created instead of 2 and I suspect the
> tveeprom error is fatal.
>
> Does anyone have any suggestions?
>
> Thanks,
> Martin
> -- 
> 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
>

Read the topmost note of:

http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers

Is your device in any way related to those two iterations of the
Hauppauge HVR-2200 model?

(http://linuxtv.org/hg/v4l-dvb/file/304cfde05b3f/linux/Documentation/video4linux/CARDLIST.saa7164)


--
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: is the list down?

[CityK]

  Jed wrote:
> nope got that, but not getting other people's emails. weird.


Maybe its amnesia?

http://www.mail-archive.com/linux-media@vger.kernel.org/msg19011.html

"I'm unsubscribing from this list..."


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

a short video that developers will likely enjoy

[CityK]

The following is a link to an approx. 11min video. The connection pt. to
what you are doing here comes in it in around the 8 min mark, so bear
with it (though I highly doubt it will be in any way insufferable).  I
hope you enjoy this little diversion (I think most will).

http://www.youtube.com/watch?v=u6XAPnuFjJc


--
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: TBS 6980 Dual Tuner PCI-e card.....not in Wiki at all?

[CityK]

Another Sillyname wrote:
> Guys
>
> The TBS 6920 PCI-e card is in the Wiki and is a supported card.
>
> The TBS 6980 dual tuner PCI-e card is not in the Wiki at all, is there
> a reason for this given they have released a non GPL blob at least?
>   

Because the wiki relies upon user contributions.  No contributions, no
information.  Simple as that.


> Also is there a reason that an indicative price for supported cards is
> not shown in the wiki?  It would save a load of time rather then
> having to search on each card only to find out it's ridiculously
> priced at $1000.

I for one am not particularly keen on inclusion of prices because:
- prices are highly subject to temporal variance (i.e. what costs $150
now could be $80 in six months)
- prices are often highly variant across broad geographical regions
(i.e. what costs $70US in America could, after accounting for exchange
rates, cost an equivalent of $100US within Canada)
- prices are often highly variant within local geographical markets (i.e
what costs $99 at the local big box Bestbuy store could easily cost $79
at the local mom&pop computer store)
- prices require regular updating/maintenance in order for them to be in
any way "indicative" ... the wiki relies upon user contributions ...
ergo, I can already tell you in advance that its not going to happen
(because its a time consuming endeavour, and there is no critical mass
of contributors to keep the information relevant), and so, any original
submissions will inevitably just end up suffering information rot (and,
thus, end up not being indicative or of particular use for the end user).
--
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: Pinnacle PCTV DVB-T 70e

[CityK]

Hi Alex,

this list is all but dead. Use the linux-media mailing list instead (I
have cc'ed my reply to it).in the olden days, the video4linux list
was the correct one for analog devices, and linux-dvb for (surprise,
surprise) dvb related discussion. Nowadays, they have both been
superseded by the linux-media list.

> Long time I try to run a particular type of device DVB-T, and sometimes I did.
>
> The device in question is a Usbstick Pinnacle PCTV DVB-T (70th); is
> USB, running lsusb we have this
>
> eb1a:2870 eMPIA Technology, Inc. Pinnacle PCTV Stick
>
> As I said before, once I managed to get it working with both Fedora
> and Slackware (the Linux distributions that I use routinely).
>
> Did not work with the drivers on the kernel (em28xx, em28xx-dvb); the
> "traditional driver" try to recognize the device, but doesn't work.
>
> The device works only (and very well) with a version made by some
> individuals, called em28xx-new. There is a version of these drivers,
> compile manually, but it works only until kernel 2.6.31 (
> http://launchpadlibrarian.net/35049921/em28xx-new.tar.gz )
>   

He stopped supporting his driver and now only works on closed source
software.

> Searching the internet I saw that many users are trying to work this
> board (very common).
>
> Is there a way to incorporate the changes mentioned in the official driver?
>   

No.

> Or, you can suggest how they might be modified drivers indicated to
> work with recent kernels (2.6.32, and soon 2.6.33 or later)?
>   

The person in question, unfortunately and needlessly, came to an impasse
with the v4l-dvb project. He later stopped developing his work. And no
one here is much interested in touching his with a hundred and ten foot
pole.

You can, however, look to see if you can add support for your device to
the existing v4l-dvb kernel driver. There are several developers that
are knowledgeable of the em28xx driver, and whom may be able to help you
in that regard, but you will have to gain there attention first.

--
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: No video0, /dev/dvb/adapter0 present

[CityK]

Cliffe,

Your card does not support analogue, hence there will be no /dev/videoN
node created.  You are most likely attempting to use analogue tv viewing
applications (i.e. xawtv v3.9x, tvtime, ...). Use applications for
digital tv instead (i.e. kaffiene).

If you go back over the "How to Obtain, Build and Install V4L-DVB Device
Drivers" article, you will find links to two other articles

http://www.linuxtv.org/wiki/index.php/What_is_V4L_or_DVB%3F
http://www.linuxtv.org/wiki/index.php/Device_nodes_and_character_devices

which should provide you with fuller details.
--
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

video4linux-l...@redhat.com

[CityK]

On the video4linux mailing list,

Nicolas Riendeau wrote:
> Mark wrote:
>> what's the right list?
>>
>
> This mailing list is essentially dead (I must confess I wonder why
> they haven't deleted it).

Indeed. At this point, its become a community disservice not to have a
redirect/pointer to the new list.

Is there anyone at Red Hat who can set up an auto reply redirector to
the Linux Media Mailing List
(http://vger.kernel.org/vger-lists.html#linux-media ) for any new mails
set into the v4l mailing list?

I don't know how many people are still subscribed to the v4l, but that
number is got to be dwindling, and I think its long about past the time
that we turn the lights off.
--
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: [Bulk] Need Info

[CityK]

Hi,

the video4linux mailing list is all but dead and has been superseded by
the linux-media mailing list (Lmml). I've cc'ed the Lmml with this reply.


linux newbie wrote:
> Hi,
>
> On my embedded PXA255 platform, we have working USB module. ISP1362 is the
> controller. Recently we want to integrate Microsoft Lifecam Cinema webcam
> and want to take still images.
>
> Linux kernel is 2.6.26.3 and we enabled V4L2 and UVC class drivers. On
> plugging the Cam and querying the proc and sys file system, I can able to
> view cam details.
>
> I want to capture the frame (preferably in jpeg) and write to a file. Is
> there any example code for that? I went through the below web page
> http://v4l2spec.bytesex.org/spec/capture-example.html, but if you can
> suggest some more example, it will be of great help to me.
>
> Thanks
> --
> video4linux-list mailing list
> Unsubscribe mailto:video4linux-list-requ...@redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/video4linux-list
>
>   

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

[CityK]

Hi Carlos,

the video4linux mailing list is all but dead and has been superseded by
the linux-media mailing list (Lmml). I've cc'ed the Lmml with this reply.

Carlos Lavin wrote:
> hello, I am develop a driver for a sensor of omnivision ov7670 for work only
> soc-camera subsystem in the version 2.6.30. I have a problem with the hue,
> when I put the color bars after DSP, the color fo this bars aren't corrects,
> the hue function are same that the ov7670 mainline. any body know anything
> about this topic?
--
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: Kworld 315U and SAA7113?

[CityK]

Franklin Meng wrote:
> As far as I can tell, the Kworld 315U is the only board that uses this 
> combination of parts..  Thomson tuner, LG demod, and SAA7113.  I don't think 
> any other device has used the SAA7113 together with a digital demod.  Most 
> products seem to only have the SAA711X on an analog only board.  Since I 
> don't have any other USB adapters with the SAA chip I was unable to do any 
> further testing on the SAA code changes.  
>   

IIRC, a couple of the Sasem/OnAir devices use a saa7113 together with a
digital demod. I seem to also recall something else, though maybe I'm
mistaken.
--
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: i915 graphics driver

[CityK]

Neil Sikka wrote:
> hey. isnt this mailing list where the i915 driver was developed?
>
> On Wed, Dec 30, 2009 at 4:53 PM, CityK  wrote:
>   
>> wrong list Neil -- try xorg user support:
>> http://lists.freedesktop.org/mailman/listinfo/xorg

(note: added LMML back in .. use "reply all")

nope.  likely on http://lists.freedesktop.org/archives/intel-gfx/  (or
some precursor ... see http://intellinuxgraphics.org/  ).  Anyway, xorg
or the Intel list would likely serve your purposes
--
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: [Bulk] help on mercurial

[CityK]

Karicheri, Muralidharan wrote:
> I am trying to learn mercurial for hosting my own hg tree and ended up here 
> :(. 
>
> Any help will be appreciated.

Hi,
see the following link, as it has embedded links for what your after:
http://www.linuxtv.org/wiki/index.php/Maintaining_Mercurial_(Hg)_trees

--
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: Status of Terratec S7 drivers

[CityK]

Hi

Daniele Venzano wrote:
> Hello,
> at this URL:
> http://linux.terratec.de/tv_en.html
>
> there is a driver package for the Terratec S7 DVB-S/S2 USB.
>
> I'd like to know if they are (1) working 

no idea, but perhaps someone else knows, or you could try them yourself
(slash volunteer to be the guinea pig for everyone else) if you have the
hardware


> and (2) being considered for
> inclusion in the dvb tree.
>   

no idea if anyone at Terratec is working in conjunction with v4l-dvb, or
has plans for its inclusion into the kernel ... there may already be
such work/plans, but I'm ignorant of such. In any regards, if they are
interested, then they should for the following instructions on route to
achieving that purpose:
http://www.linuxtv.org/wiki/index.php/Development:_How_to_submit_patches
--
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: i915 graphics driver

[CityK]

wrong list Neil -- try xorg user support: 
http://lists.freedesktop.org/mailman/listinfo/xorg
--
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: [linux-dvb] Linuxtv wiki needs email notification/more email-ready users

[CityK]

Hi Henrik,

CityK wrote:
> H. Langos wrote:
>   
>> ...I'd like to keep an eye on changes. Not because of fear of
>> vandalisim but because changes to the templates/date potentially have 
>> effects on a lot of pages.
>>
>> There are some people who day by day put a lot of effort and work into the 
>> wiki and I'd like to thank them all for their continuing effort. I myself 
>> have only occasionaly time to update information there and I miss a lot
>> of changes, even to the pages I watch, because the "watchlist" and "recent
>> cahnges" reaches only seven days back. Manually going through the pages on 
>> my watchlist (currently 57) is not what I'd call good use of resources.
>>
>> It would be great if it was possible to get (immediate/daily/weekly?) change
>> notifications by email in order not to lose track of what is happening to
>> the pages that I care about. (I bet this is standard functionality of
>> mediawiki or at least one of the more common extentions.)
>> 

In searching for something else, I came across this recent thread on the
mediawiki m/l:
http://lists.wikimedia.org/pipermail/mediawiki-l/2009-October/032214.html

There are a few suggestions in it (I just skimmed through). Perhaps one
of them would be good to implement.
--
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: [Bulk] V4L-DVB Summit Day 3

[CityK]

Hans Verkuil wrote:
> I made the following list:
>
> - We created a new mc mailinglist: linux...@googlegroups.com
>
> This is a temporary mailinglist where we can post and review patches during 
> prototyping of the mc API. We don't want to flood the linux-media list with 
> those patches since that is already quite high-volume.
>
> The mailinglist should be active, although I couldn't find it yet from 
> www.googlegroups.com. I'm not sure if it hasn't shown up yet, or if I did 
> something wrong.
>   

I'm scratching my head on this one.  Seems the last thing that is needed
is YET another mailing list.  Further, it
- fractures the development community. 
- persons unaware of the decision, and whom might be interested, would
never find it . i.e. alienation
- disinterested parties can simply hit the delete key and not bother
with the message
- blah blah blah ..

PS.  In regards to yesterday's business announcements, I hope your new
forthcoming overlords are as kind to you as your last
--
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: [linux-dvb] Any PCIe DVB-T Dual Tuner cards yet working under Linux?

[CityK]

Christophe Boyanique wrote:
> Hello,,
>
>   
>> Is anyone on the list currently using a DVB-T card that has DUAL
>> tuners (i.e. I'm looking to replace Hauppage 500's which work great).
>> 
>
> That is an excellent question 

Which has actually been posed a couple of times in the recent months.
Try a search on:

http://www.mail-archive.com/linux-media@vger.kernel.org/

using "dual" you'll find one of them quickly enough at least
--
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: [OT] analogue sat card

[CityK]

Simon Kenyon wrote:
> i realise that this is a bit [OT]
> but does anyone know of a (linux supported) analog PAL sat card?
> there are still some broadcasts on astra 19.2E 

Hi Simon,

Not at all off topic.  I can think of two ancient TechniSat PCI cards
that you might be able to get hold of off the likes of ebay.  Working
drivers for which, however, is a different matter -- although that
situation could likely be remedied without too much difficulty by anyone
determined.  Follow the rabbit:

* http://www.linuxtv.org/wiki/index.php/TechniSat_TechniPC/Mediafocus_I
** http://www.linuxtv.org/wiki/index.php/TechniSat_Mediafocus_II

I also vaguely recall a few other analogue sat cards, but I don't think
they ever had any Linux related support.  You could try scanning through
the bttv-gallery
(http://www.linuxtv.org/wiki/index.php/Development:_How_to_add_support_for_a_device#bttv-gallery)
 
to see if Gunther had captured any such info.
--
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: [linux-dvb] Linuxtv wiki needs email notification/more email-ready users

[CityK]

H. Langos wrote:
> Hi there,
>
> after a while I decided to come back to the linuxtv wiki to finish
> organizing the bazillion dvb-t usb devices in a way that helps 
> a) normal users to find out if a certain device is supported and 
> b) developers to update information on the drivers they manage.
>
> Some preview of this can be seen on my playground page:
> http://www.linuxtv.org/wiki/index.php/HLPlayground2
>
> As this is a more complicated way of storing the information than just plain
> tables, I'd like to keep an eye on changes. Not because of fear of
> vandalisim but because changes to the templates/date potentially have 
> effects on a lot of pages.
>
> There are some people who day by day put a lot of effort and work into the 
> wiki and I'd like to thank them all for their continuing effort. I myself 
> have only occasionaly time to update information there and I miss a lot
> of changes, even to the pages I watch, because the "watchlist" and "recent
> cahnges" reaches only seven days back. Manually going through the pages on 
> my watchlist (currently 57) is not what I'd call good use of resources.
>
> It would be great if it was possible to get (immediate/daily/weekly?) change
> notifications by email in order not to lose track of what is happening to
> the pages that I care about. (I bet this is standard functionality of
> mediawiki or at least one of the more common extentions.)
>
>
> Also I'd like to encourage new and existing users to add their email address 
> to their profile AND to check the "Enable e-mail from other users" box.
> Maybe we could change the default to enable that box?
> That way it is possible to ask for missing details if somebody adds a new
> device, or to send hints if somebody writes in an article that a certain
> device doesn't work. Or to simply write a short note when removing some
> information like "Hey dude, I just removed some information that you added 
> to article X because it is already contained in article Y. Instead I've 
> added a link to Y. Thank you for your help and keep up the good work!..."
>
> Also developers could ask people who are interested in a device's driver to 
> check out a new version as soon as it is ready. 
>
> All in all it would improve the user experience and the quality of 
> information 
> on the wiki as feedback would not have to go through the "discussion" pages. 
>
> I went that way when talking to some other wiki admins about my efforts to 
> unify the usb dvb-t data and the experience shows that wiki's are not a 
> good medium for serious discussions.
>
> cheers
> -henrik
>   

(I've cc'ed the LMML to reach the wider audience nowadays)

These are good suggestions that Henrik has made. I would encourage
others to also step up and try to find ways to implement them (along
with any other improvements that can be made to the wiki and other
sources of V4L-DVB documentation and website -- the website, in
particular, really could stand for an overhaul).

(Note - at present I do not have time to take on further work, nor do I
personally really want the responsibility of being the point man for
such changes ... as it stands, I'm interested only in finishing off
ventures I commenced long ago ... or introducing changes that are
personally enjoyable to myself to make)

I also note that from prior discussions with Henrik and Jim (and Henrik
is absolutely correct that discussing things from within the wiki
quickly becomes difficult to follow), and from prior times with Micheal
and Devin on irc, that we were touching upon the idea of a database. One
such example that I recently came across, and that is worth further
investigation by someone (and, again, that someone does not include me),
is that model used by dd-wrt for their supported hardware (i would link,
but it appears that their server is down at the moment).


--
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: LinuxTV firmware blocks all wireless connections / traffic

[CityK]

Aleksandr V. Piskunov wrote:
> I'm getting closer to pinpointing the real problem and so far
> everything points to AMD SB700 chipset driver. Google says it has quite
> some hardware bugs and several workarounds in linux drivers...

If your googling didn't turn them up already, here's some more threads:

http://www.mail-archive.com/search?q=SB700+&l=linux-media%40vger.kernel.org
--
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: NTSC/ATSC device recommendation

[CityK]

Ben Swartzlander wrote:
> rra...@comcast.net wrote:
>> I would like to purchase a NTSC/ATSC device that is functional under
>> Linux
>> MY only requirement is receiving FTA broadcast
>> Would y'all recommend a USB device or better to stick with a pci device
>> I have followed this list and have only become more confused
>>
>> Thanks
>> Richard
>
> I have 2 Hauppauge WinTV-HVR-850 USB sticks in my MythTV box (Ubuntu
> 8.04). USB is preferable to PCI for all kinds of reasons. I bought
> mine here:
> http://www.newegg.com/Product/Product.aspx?Item=N82E16815116031
>
> Note that if you go with this device, you'll need to manually add the
> firmware to your /lib/firmware directory. You can get the firmware
> here: http://www.steventoth.net/linux/xc5000/
>
> There are plenty of other supported devices though. When I was doing
> my research, this page was an extremely useful resource for Linux ATSC
> hardware: http://www.linuxtv.org/wiki/index.php/ATSC_Devices

That last comment made me happy to know.

Anyway, please note that this mailing list is pretty much deprecated in
favour of the LMML (which I've cc'ed in this reply).

--
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: Question on video device in /dev for S460 card cx88

[CityK]

Peter Brouwer wrote:
> Hello
>
> Quick question regarding video devices that show up when using a cx88
> base S460
> (tevii) DVB-S2 card.
>
> I see two devices in /dev
> /dev/video0 and /dev/vbi0 related to the cx88 based dvb-s2 card.
> What are those devices, is the video0 the video out of the card after the
> demuxer? If so, should that device not show up in /dev/dvb/adapterN ??
>
> What is the /dev/vbi0 device?
>
> Regards

I heavily modified/updated my previous link/answer I provided to this
question you posted earlier.  A more thorough answer can be found here:
http://www.linuxtv.org/wiki/index.php/Device_nodes_and_character_devices

Please review that, as it should make clear the answers to your questions.
--
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: xf86-video-v4l

[CityK]

Stefan Sassenberg wrote:
> Hello,
>
> what does the xf86-video-v4l driver do? I think I know the purpose of
> xf86-video- drivers, but I don't know what the -v4l
> does. How is it used?
>
> Regards
>
> Stefan


Hi, please note that this mailing list is pretty much deprecated in
favour of the Linux-Media Mailing List (LMML) -- many key individuals
have already left the building (i.e. unsubscribed and participate only
on LMML nowadays).

Anyway, in answer to your question:
* from the command line, type "man v4l"
Then supplement that info with the following points taken from the V4L2
API
(http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec-single/v4l2.html):
*
http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec-single/v4l2.html#id3069581
**
http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec-single/v4l2.html#ftn.id3069581
*
http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec-single/v4l2.html#xvideo






--
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: problem building v4l2-spec from docbook source

[CityK]

Mauro Carvalho Chehab wrote:
> Em Sun, 6 Sep 2009 22:25:25 -0300
> Mauro Carvalho Chehab  escreveu:
>
>   
>> Em Sat, 05 Sep 2009 18:54:27 +0100
>> Peter Brouwer  escreveu:
>>
>> 
>>> Is it possible to create a link on the linuxtv.org website to the latest 
>>> dvb and 
>>> v4l spec in pdf?
>>> For dvb the v3 is still on the documentation page.
>>>   
>> The pdf version of V4L2 spec is currently broken: several tables and graphics
>> don't fit at the page size. If you (or someone else) is interested on fixing
>> it, I'll add a pointer at linuxtv.org  for the updated version, and improve 
>> the
>> script to auto-generate it.
>>
>> In the case of the DVB spec, the version of the current document is version 
>> 3.
>> Patrick's ISDB-T patch series are increasing version to 5.1, but there are
>> still some missing parts when comparing with the current API.
>>
>> In order to make easier for people to maintain the DVB API and to allow 
>> people
>> of just using just one language and document generation tools, I've 
>> converted the
>> DVB API specs to DocBook as well. I'll add it to the tree soon. It is yet a
>> work undergoing, but it would be nice if people could review it and improve.
>> After having some review and porting the ISDB-T changes to it, IMO, the 
>> better
>> is to deprecate the LaTex version using the DocBooc version one instead.
>>
>> 
>
> I've updated the Documentation page at linuxtv.org to warn people to not trust
> at V4L2 spec pdf file, while nobody fixes it. I also added there a link to the
> dvbapi spec generated via the newly DocBook port of the docs that I posted at:
>   http://linuxtv.org/hg/~mchehab/dvb-specs
>
> This way, it will be easier for people to double check if nothing were lost
> during the format conversion. IMHO, one of the biggest advantage of the html
> generated from DocBook is that the chapter/section numbering is preserved,
> while, with the LaTex version, they are shown only at the pdf doc. It should 
> be
> noticed that, as no styles are applied to the tables, that they are not
> nicely displayed at the DocBook version.
>   

We've got too many entry points/links to things -- which lends itself to
becoming a maintenance nightmare  (not blaming anyone, just pointing out
the obvious).  For example:  although the updated info was applied here:
http://www.linuxtv.org/docs.php, we have other avenues such as
http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/  (as linked
to by, for example,  from here
:http://www.linuxtv.org/wiki/index.php/Development:_Video4Linux_APIs)
that do not reflect those changes, and hence we have inconsistent info
across the board. 

Same goes with mailing lists and #irc channels -- we've got too many of
them! ... /trails off mumbling about this and thatmumble mumble
mumble grumble
--
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: Should I see a videoN and audioN in /dev/dvb/adapterN??

[CityK]

Peter Brouwer wrote:
> I am using a S460 Tevii ( Cx88) and a nova T 500 card.
> I see three adapter directories ( T 500 is dual tuner).
> Each has demux0 frontend0 net0 and dvr0
>
> Should I not see a video0 and audio0 in each of them too?
> I see one /dev/video0 and one /dev/vbi0 that seems to belong to the
> S460 card
>

See here: http://www.linuxtv.org/wiki/index.php/Device_nodes
--
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] Leadtek WinFast DTV-1800H support

[CityK]

Miroslav Šustek wrote:
> Any problem with this patch?
> I'm trying to get WinFast DTV-1800H support into repository for seven months.
> (see:
> http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/1125/match=1800h
>
>   

Hi Miro,

Its unfortunate that the patch hasn't been added yet, but I do see a
problem (in its current form) that explains why it hasn't been picked
up.   For the sake of thoroughness, here's an audit trail of the entire
history:

1) http://linuxtv.org/pipermail/linux-dvb/2008-October/029859.html
- Steve picked up some style flaws
- (Although it is more desirable to include patches inline as opposed to
as attachments, I note that the attached patch is of type
"text/x-patch", which is fine)

2) http://linuxtv.org/pipermail/linux-dvb/2008-November/030362.html
- I noticed your missing SOB
- (Again, I note that the attached patch is of type "text/x-patch",
which is fine)

3)
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/1125/match=1800h
- You note in your message that your prior patch didn't get picked up
possibly because of the switch of mail lists.  That is quite possible,
but whatever the case, your patch was, indeed, lost.
- Herman responded with some suggestions, as well as noting that your
SOB was absent again with the attached patches (though, I know you had
resubmitted back in Nov with a SOB)
- But here starts the most recent problem: unfortunately, the attached
patches where of type "application/octet-stream", which the patchwork
tool will NOT pick up.  Please see:
http://www.linuxtv.org/wiki/index.php/Development:_How_to_submit_patches
This is a summary explanation of the submitting process (which includes
links to several of the documents you've undoubtedly already read) and
touches upon attachments.

4) http://www.mail-archive.com/linux-media@vger.kernel.org/msg05856.html
-  in Hermann's follow up, he correctly notes that the patches never
made it onto the patchwork queue (see my explanation directly above for
why they were not).

5) http://www.mail-archive.com/linux-media@vger.kernel.org/msg05888.html
> Nobody noticed the previous post(s).
>   
- Ha, I beg to differ! -- at the very least, Steve, myself and Hermann
have all spotted your prior patches and have commented.
- Unfortunately, the attached patch is again of the type
"application/octet-stream" and will NOT be automatically picked up by
patchwork


6) http://www.mail-archive.com/linux-media@vger.kernel.org/msg05890.html
> (Shoot me! Now it's correct.)
>   
- Nope.  The attached patch is still a type "application/octet-stream",
and that is why it is not showing up on the patchwork queue list
- I have also just noticed that Trent has also now commented on the
patches (so add another to the list!)

/End of audit trail

I understand your frustration and I don't mean to be bureaucratic (I
have zero say in what patches get picked up), but I hope I have shed
some light upon what has gone wrong over the last several months. 
Although I'd rather suspect that Mauro is now well aware of the issue,
I'd urge you to resubmit (following the recommendations from the link I
provided above) so that it gets picked up and placed upon the patchwork
list.




--
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: EC168 "dvb_usb: Unknown symbol release_firmware"

[CityK]

drbob,

Off_Topic: that name takes me back: http://muppet.wikia.com/wiki/Dr._Bob

On_Topic:  You have built the drivers but you haven't installed them
into the system as intended, consequently you will run into the set of
observations that you have.  Have a read through:
http://www.linuxtv.org/wiki/index.php/How_to_Obtain%2C_Build_and_Install_V4L-DVB_Device_Drivers





--
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 3/6] ir-kbd-i2c: Switch to the new-style device binding model

[CityK]

Mauro Carvalho Chehab wrote:
> On Tue, 07 Apr 2009 23:02:43 -0400
> CityK  wrote:
>
>   
>> Regarding the KS003 (& KS007; the other "mystery" chip):
>>
>> Upon further investigation of some info from a post from last year
>> (http://www.linuxtv.org/pipermail/linux-dvb/2008-January/022634.html),
>> it appears that these (assuming that they are the same IC across the
>> various MSI, Leadtek & KWorld cards; and I believe that to be true) are
>> the "AT8PS54/S56" chip from "Feeling Technology" ... the datasheet for
>> that part is available through a google search  probing further (as
>> I had never heard of FT before and so I looked them up), it looks like
>> FT renamed and/or upgraded the chip to the "FM8PS54/S56" ... the near
>> identical datasheet for that second version is also available:
>> http://www.feeling-tech.com.tw/km-master/front/bin/ptdetail.phtml?Part=M1-05&Category=100018
>> 
>
> From what I've investigated, several of those IR chips are micro-controllers 
> like
> the one you pointed. I've seen a few boards whose IR chip is not masked. On
> those, I always went into some micro-controller datasheet.
>
> Those IR's with a micro-controller have some software inside it to decode one 
> IR
> protocol and generate scan-code sequences that can be received via GPIO or via
> I2C, depending on the firmware content.
>
> The datasheet of those chips are useless, since the behaviour of the
> device is programmed inside their ROM/EEPROM [1]. So, even being the same 
> chip,
> you could have two "K007" devices with different firmwares, listening on
> different i2c addresses and eventually generating different scan-codes for the
> same IR.
>
> On the other hand, for USB devices and for bttv, saa7134 and cx88, there are
> some easy ways to monitor what i2c messages or GPIO pins are involved with IR.
> In general, the IR received messages generated by the firmware are some 
> header,
> a scan code, a repeat key bit and a trailer. So, it is not hard to generate a
> get-key routine to get the scan code and the repeat bit from the protocol.
>
> That's why the modern ir-kbd-i2c approach is to select the proper IR 
> parameters
> after binding the module, at the bridge driver. The bridge driver is the one
> who knows what's the IR scan code of the original IR (to set it as the
> default), and the proper get-key function. With the new i2c behaviour, the
> bridge driver can also specify the proper i2c address for each device.
>
> Cheers,
> Mauro
>
> [1] It doesn't seem to be practical for me to get their internal software.In
> general, such micro-controllers block EEPROM/ROM read of the software inside.
> If this is the case of this chip, the only remaining option to get the 
> internal
> software would be to cut the plastic and try to see the state of each eeprom
> bit with the help of a good microscope. 
> Anyway, assuming that there are some way to read the ROM content, in order to
> see the device behavior, one should remove the chip from the board, get the
> ROM/EEPROM content, write a disassembler for this processor, disassemble the
> code and analyse the results. This would be a real hard work, would take a lot
> of time, and I doubt that this would help to improve the driver, since we
> already know how to read scan codes from those devices.

Thanks for the detailed response Mauro. I've actually been wondering
about whether the specific "KS00x" designation/label might refer to the
embedded firmware or to a dataline, so that thought is certainly
consistent with your description.
--
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 3/6] ir-kbd-i2c: Switch to the new-style device binding model

[CityK]

Jean Delvare wrote:
> On Mon, 06 Apr 2009 23:10:36 +0200, hermann pitton wrote:
>   
>> Am Montag, den 06.04.2009, 10:40 +0200 schrieb Jean Delvare:
>> 
>>> Anyone out there with a MSI t...@nywhere Plus that could help with
>>> testing?
>>>   
>> Here is a link to one of the initial reports by Henry, others are close
>> to it.
>>
>> http://marc.info/?l=linux-video&m=113324147429459&w=2
>>
>> There are two different variants of that MSI card, but that undocumented
>> KS003 chip is the same on them.
>> 
>
> Great, thanks for the pointer. If I understand correctly, the KS003
> has a state machine flow which causes the chip to stop answering when
> an invalid address is used on the bus and start answering again when a
> valid address other than his own is used. As the old i2c model relied a
> lot on probing, I am not surprised that this was a problem in the past.
> But with the new model, probes should become infrequent, so I suspect
> that the workaround may no longer be needed... except when i2c_scan=1
> is used.
>
> I'd rather keep the workaround in place for the time being, and only
> once the ir-kbd-i2c changes have settled, try to remove it if someone
> really cares.

Regarding the KS003 (& KS007; the other "mystery" chip):

Upon further investigation of some info from a post from last year
(http://www.linuxtv.org/pipermail/linux-dvb/2008-January/022634.html),
it appears that these (assuming that they are the same IC across the
various MSI, Leadtek & KWorld cards; and I believe that to be true) are
the "AT8PS54/S56" chip from "Feeling Technology" ... the datasheet for
that part is available through a google search  probing further (as
I had never heard of FT before and so I looked them up), it looks like
FT renamed and/or upgraded the chip to the "FM8PS54/S56" ... the near
identical datasheet for that second version is also available:
http://www.feeling-tech.com.tw/km-master/front/bin/ptdetail.phtml?Part=M1-05&Category=100018

--
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: ASUS My Cinema-PHC3-100/NAQ/FM/AV/RC Support?

[CityK]

U. Artie Eoff wrote:
> I recently purchased a ASUS My Cinema-PHC3-100/NAQ/FM/AV/RC ATSC tv tuner
> card.  I've done some searching to see what kind of support is available for
> using it under Linux.  There is nothing out there that mentions it will work
> or how to get it to work.  And it does not appear that my Fedora OS detects
> it installed.  Could someone start me off with some steps on getting it
> configured (i.e. drivers, detecting, loading, configuring, etc.).  I
> consider myself a somewhat advanced user of Linux, but have never done any
> direct work with tuner cards or general low-level hardware configuration
> under Linux.  So, don't hesitate to explain in technical terms if it is
> easier.
>   

suscipio lackius -- a technical term, derived from Coyote and Road
Runner Latin, which literally translates into "support lacking" or, from
a contemporary perspective, "not supported".  Sorry.  Hopefully the
humour eased the pain.

> Anyway, here is the product link for my card:
> http://www.asus.com/products.aspx?l1=18&l2=83&l3=794
> ...and product image:
> http://www.asus.com/prog_content/middle_enlargement.aspx?model=2524
>   

>From your provided link, it is apparent that this is another variation
of the ViXS Puretv reference design(s).  Up to this point, in PCI
flavour, I had only seen a half height card design.  Examples:
- Vista View Saber DA-1N1-I (http://www.vistaview.tv/saber-da-1n1-i.html)
- Samsung Combo-210
(http://www.geeks.com/details.asp?invtid=COMBO-210-BULK&cat=VID)
- ViXS PureTV-U 48A3 (
http://www.linuxtv.org/wiki/index.php/ViXS_PureTV-U_48A3) 

As I've seen a couple of other PureTV-U model numbers listed (without
actually having seen the cards), it is likely that your full height PCI
card is the equivalent of one of them.  I would go a step further and
call your card pretty much a PCI hybrid of the Samsung type PCIe design;
have a look at:
- Vista View Saber DA-1N1-E (http://www.vistaview.tv/content/view/51/116/)
- Samsung Combo-210E
(http://tekgems.com/Products/et-46138-vid-combo-210e-bulk.htm)

Note that with the Vista View PCIe card, it looks like the LG demod is
on the front face. (In the half height PCI design, the LG demod is on
the back side of the card). 
In the Samsung PCIe card, there is a much smaller chip in the spot where
the LG demod resides on the Vista View PCIe version.  Similarly, your
card also appears to copy the Samsung layout/componentrywith the
minor exceptions related to the difference in interface

I suggest contacting ViXS and inquire as to whether they intend to
provide Linux support for their chip; there is some evidence that
suggests that they may very well be interested
(http://www.vixs.com/sections/careers/job_software_driver_engineer.htm). 
Other then that, I suspect that the other components used by the card
already have driver support, or are presently being worked upon (i.e.
saa7136) in conjunction for other projects.  Once those individual items
are all supported, device level support would certainly be feasible to
obtain.



--
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] Add "Sony PlayTV" to dibcom driver

[CityK]

Mauro Carvalho Chehab wrote:
> On Sun, 22 Feb 2009 15:04:13 -0500 CityK  wrote:
>> I don't think the Patchwork tool picked it up, as I don't see it in the
>> queue :(
>> http://patchwork.kernel.org/project/linux-media/list/
>>
>> I'm wondering it the quotations in the subject line are enough to throw
>> the script off.  Mauro, any ideas?
>> 
>
> In general those tools to pick and work with scripts don't like very much
> inlined patches, although it generally works.
>
> Also, it requires that the patch is not line wrapped.
>
> In this specific case, the patch is line-wrapped:
>
> --- 
> v4l-dvb-359d95e1d541-vanilla/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
> 2009-02-18
> 13:49:37.0 +0100
> +++ v4l-dvb-359d95e1d541/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
> 2009-02-18
> 23:45:43.0 +0100
>
> instead of:
>
> --- 
> v4l-dvb-359d95e1d541-vanilla/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
> 2009-02-18 13:49:37.0 +0100
> +++ v4l-dvb-359d95e1d541/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
> 2009-02-18 23:45:43.0 +0100
>
>
> So, it doesn't apply as a patch and patchwork discards it.

Ahh, thanks for the explanation. Its strange that they are not tailored
for inline patches, given that that is precisely the preferred and
prescribed submission method!
--
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: [Bulk] Re: POLL: for/against dropping support for kernels < 2.6.22

[CityK]

Andy Walls wrote:
> On Sun, 2009-02-22 at 14:12 -0500, CityK wrote:
>
>   
>> The V4L-DVB is lacking in strategic direction.  Yesterday was the time
>> to adopt one; so lets pick up one today!
>> 
>
> CityK,
>
> I see you've been reading (or channeling) my blathering:
>
> http://www.linuxtv.org/irc/v4l/index.php?date=2009-02-20
>
> ([19:42] to [20:21])
>
> Regards,
> Andy

Rabble Rabble Rabble! (
http://www.urbandictionary.com/define.php?term=RABBLE RABBLE RABBLE! )
--
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: vbox cat's eye 3560 usb device

[CityK]

Amy Overmyer wrote:
>> Lastly, are there any other IC components on the back or front of the
>> PCB ?  Can you provide pics (upload them to the wiki article)) ?
>> 
>
> The back only has a couple components, probably for electrical, no ICs.
>   
okay

> The
> front only has the cypress (100 pin pkg) chip and the NIM, with a
> couple small components, that I can't read what they are. The PCB is
> stamped osc by one of them and usbid on the other, so I'm guessing one
> is an oscillator and the other the PROM where the cold USB id is stored.
>   

okay. I rather imagine that your guesses are correct

> I
> opened up the NIM (hey, they're $30 at my local computer store right
> now, so even if I kill it, I have an extra), and I saw my old friend
> the BCM3510 (I have a 1rst gen air2pc pci card that works pretty well
> for me)
Wow, I'm kind of surprised about that one -- I would have expected the
NIM to have been a little more contemporary (given that I believe these
devices (150/151/3560) came out in the ~2005 time frame).

> and a smaller chip marked tua6030 (or could be 6080, the
> writing is faint, but infineon doesn't look like they make an 6080). 
>   

Yes, that would be 6030

> I have photos but need to upload them.
>   
okay


This device might also be close in design to the original Technisat
Air2PC-ATSC-USB device
(http://www.linuxtv.org/wiki/index.php/TechniSat_Air2PC-ATSC-USB) --
though, obviously it doesn't use a Flexcop controller ... I say might
be, as I don't know what the USB bridge is in the Technisat device, nor
the exact tuner module employed. Patrick might recall though


--
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: Newbie question about cheap 4ch security card

[CityK]

Riba Zoltán wrote:
> Hi,
>
> I want to get working this card under my Debian
> :(2.6.24-etchnhalf.1-686 on i686)
>
> http://www.zoneminder.com/wiki/index.php/Image:4ch_DVR_card.jpg
>
> But it doesn't want...:
> dmesg:
>
> bttv: driver version 0.9.17 loaded
> bttv: using 8 buffers with 2080k (520 pages) each for capture
> bttv: Host bridge needs ETBF enabled.
> bttv: Bt8xx card found (0).
> PCI: Found IRQ 15 for device :00:12.0
> PCI: Sharing IRQ 15 with :00:07.2
> PCI: Sharing IRQ 15 with :00:0b.0
> FPCI: Sharing IRQ 15 with :00:12.1F
> bttv0: Bt878 (rev 17) at :00:12.0, irq: 15, latency: 32, mmio:
> 0xd7001000
> bttv0: using: GrandTec Multi Capture Card (Bt878) [card=77,insmod option]
> bttv0: enabling ETBF (430FX/VP3 compatibilty)
> bttv0: gpio: en=, out= in=00f360ff [init]
> bt878 #0 [sw]: bus seems to be busy
> bttv0: tuner absent
> bttv0: registered device video0
> bttv0: registered device vbi0
> bttv0: PLL: 28636363 => 35468950 .. ok
> bt878: AUDIO driver version 0.0.0 loaded
> bt878: Bt878 AUDIO function found (0).
> PCI: Found IRQ 15 for device :00:12.1
> PCI: Sharing IRQ 15 with :00:07.2
> PCI: Sharing IRQ 15 with :00:0b.0
> PCI: Sharing IRQ 15 with :00:12.0
> bt878_probe: card id=[0x0], Unknown card.Exiting..
> bt878: probe of :00:12.1 failed with error -22
>

> lspci -vn 
no subsystem ID reported  ... and no card id in dmesg ... I'm wondering
if there is no EEPROM on the card  also wondering if your card is
different (i.e. a new revision) from the card 77 (GrandTec Multi Capture
Card).

What happens if you don't pass a modprobe parameter (i.e. comment out
what you added in your relevant /etc/modprobe.conf file) and let the
card autodetect ... (though, as maybe surmised from my above comment,
I'm guessing a spectacular nothing )
--
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: [linux-dvb] [Bulk] Problem with TV card's sound (SAA7134)

[CityK]

panagiotis takis_rs wrote:
> > panagiotis takis_rs wrote:
> > > Hey!!
> > >
> > > I have a problem with my tv card(pinnacle pctv 310i)
> > > I can see image but i have no sound.
> > > I have tried both tvtime and kdetv.
> > >
> > > I have found this http://ubuntuforums.org/showthread.php?t=568528
> . Is it related with my problem?
> > >
> > > My tv card give audio output with this way: direct cable
> connection from
> > > tv card to sound card ( same cable witch connect cdrom and soundcard )
> >
> > I didn't read through the link you provided, but it appeared to be in
> > regards to getting audio via DMA (using the card's 7134 chip to digitize
> > the audio and send it over the PCI bus to the host system). You, on the
> > other hand, indicate that you are attempting to use the method of
> > running a patch cable between your TV card and sound card (meaning that
> > the sound card will do the digitizing instead). Question: have you
> > checked your audio mixer to make sure that any of the inputs are not
> muted?
>
> Yes i have.
> The only way i managed to get sound is these two commands:
>
>  tvtime | arecord -D hw:2,0 -r 32000 -c 2 -f S16_LE | aplay -  (out of
> sync)
>
> tvtime | sox -r 32000 -t alsa hw:2,0 -t alsa hw:0,1 | aplay -


Which, as you likely know, is essentially going the DMA route and using
the helper apps (sox, arecord) as tvtime currently doesn't support audio
DMA.

Hmm, if everything is unmuted, I have no idea why it isn't working
simply via your patch cable ... last stab at this --> how about the
leads on the patch cable itself; have you tried reversing the way one of
the ends is plugged in?
--
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: [linux-dvb] Giving Feedback (was Re: Klear?)

[CityK]

Stephen Rowles wrote:
> Only sending this to linux-dvb as I'm not signed up to the media list, and
> I'll probably get myself blacklisted from any future help by saying this
> ;) but...
>   

BANISHMENT for Rowles !!!

Just kidding. Thanks for the insightful reply.
--
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: Kworld atsc 110 nxt2004 init

[CityK]

Jonathan Isom wrote:
> Hi
> I was looking over my logs and I'm wondering is
> "nxt200x: Timeout waiting for nxt2004 to init"
> common 

No its not common

> or is this womething I need to worry about.  I got one shortly before a
> lockup(No backtrace).  Nothing was doing other than dvbstreamer sitting idle.
> I'll provide further logs if it should be needed.  I would think that
> It would need to
> only be initialize at module load.  Am I wrong in this thinking?
>
> in kernel  drivers 2.6.28.4
>
> Later
>
> Jonathan

Quick! Get out of you house now, she's about to blow !!!

Just kidding.  I don't think its anything to worry about.  The timeout
is by design (see the nxt200x.ko module).  I'm not sure why you've run
up against this; it looks to have occurred several hours after
initialization.  Perhaps a quirk in the microcode of the demod caused it.

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

[CityK]

Matthias Schwarzott wrote:
> Btw. I also had a longer look at the firmeware page in wiki and removed that 
> note about gentoo using hotplug-scripts as that is false since a long time. 
> CityK you are right, I think most (if not all) current distributions use udev 
> to create device nodes and upload firmware into the kernel.
>
>
> Yes this ebuild is there. But it is in some respect outdated, due to lack of 
> maintaining. This ebuild fetches the original files get_dvb_firmware also 
> fetches and the runs get_firmware to unpack them. (All this due to 
> license/re-distribution issues as you all know).
>   
Okay, thanks Matthias.

> But: These URLs tend to no longer work after some time, as manufacturers 
> update their drivers or web-pages :(
>
> So there should either be someone continuously updating them (in 
> get_dvb_firmware and also here in copy).
> Or: We find someone ignoring the licenses and hosting the extracted files 
> somewhere.
>
> Regards
> Matthias

I think we are stuck with the former.  But, fortunately, it looks like
schollsky is willing to be the point man :)
--
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: Aw: Re: firmware

[CityK]

scholl...@arcor.de wrote:
>  
>
>
> - Original Nachricht 
> Matthias Schwarzott wrote:
>
>   
>> Yes this ebuild is there. But it is in some respect outdated, due to lack of
>>
>> maintaining. This ebuild fetches the original files get_dvb_firmware also 
>> fetches and the runs get_firmware to unpack them. (All this due to 
>> license/re-distribution issues as you all know).
>>
>> But: These URLs tend to no longer work after some time, as manufacturers 
>> update their drivers or web-pages :(
>>
>> So there should either be someone continuously updating them (in 
>> get_dvb_firmware and also here in copy).
>> Or: We find someone ignoring the licenses and hosting the extracted files 
>> somewhere.
>> 
>
> The script "get_dvb_firmware" itself needs to be updated. I'm willing to work 
> on this
> and update necessary links and test the script for some time here on Mandriva 
> - as long
> as you're willing to help me with other distros and in the process.
>
> Any tips how to begin please?
>
> Kind regards,
>
> schollsky
>   

Hi schollsky,  that would definitely be welcomed.  You can submit
patches against get_dvb_firmware; follow instructions here:
http://www.linuxtv.org/wiki/index.php/Development:_How_to_submit_patches

--
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] Add "Sony PlayTV" to dibcom driver

[CityK]

I don't think the Patchwork tool picked it up, as I don't see it in the
queue :(
http://patchwork.kernel.org/project/linux-media/list/

I'm wondering it the quotations in the subject line are enough to throw
the script off.  Mauro, any ideas?
--
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: Fwd: [linux-dvb] dvico dual express incorrect firmware version readback!!!

[CityK]

sonof...@iinet.net.au wrote:
> On Mon Feb 16 22:51 , "sonof...@iinet.net.au"  sent:
>
>   
>>> I have done alot more testing and have found that it seems to be only after
>>> mythtv has accessed the device where this problem beings begins... 
>>>
>>>   
>> Same result with the hg version updated tonight. 
>>
>> I haven't had a chance to use another tv app yet as we are currently 
>> watching TV. 
>>
>> I will send a further update later. 
>> 
>
>
> Is anyone else actually seeing this "Incorrect Firmware Version Readback" 
> error?? 
>
> Is there something I am missing? (stupid kernel setup or something??)... 
>
> Should I  try and source the firmware again or is this unlikely to be the 
> issue?
>   

Have you tested this outside MythTV (which is a huge layer of extra
complexity) ?


--
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: PVR x50 corrupts ATSC 115 streams

[CityK]

David Engel wrote:
> I'll start with what worked.
>
> ... [test results of BER and UNC under varying configurations ] ...
>   

Steven Toth wrote:
> I think CityK confirmed that the nxt2004 driver statistics are
> probably bogus so I doubt you're going to get your 115's running with
> BER 0 regardless, which is unfortunate. 

FWIW:

I'm not seeing any UNC, just the BER (which seems consistent to most,
but not all, of David's results with varying configurations).

Presently (and a situation that is unlikely to change), I don't have an
older kernel built/installed with which I can test/confirm, but from
memory, IIRC, I believe that it must have been from around ~2.6.22 that
I recall error free femon output.

--
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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-zoran

[CityK]

Jean Delvare wrote:
>> quick question(s) - is this what I think it is -- a remote controller IC
>> ?   If so, do you know who manufactures this IC?  (I'm trying to connect
>> the dots with the problematic ks003 and ks007 ICs found on some cards)
>> 
>
> The KS0127 is a video decoder, and it's made by Samsung.

Ahh, thanks Jean
--
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: POLL: for/against dropping support for kernels < 2.6.22

[CityK]

Hans Verkuil wrote:
> Should we drop support for kernels <2.6.22 in our v4l-dvb repository?
>   

Yes


> Optional question:
>
> Why:
>   

Its causing skilled developers to waste time that would be better served
in other areas.  Because of that, these skilled volunteers are becoming
frustrated and losing their interest in pressing forth.  

It causes unnecessary complexity.  The golden rule is to keep things as
simple as possible.

It presents a hurdle to attracting new development talent (both
corporate and individual).

When upstream technical changes (such as i2c subsystem changes) have
made backporting downstream a nightmare, it is time to seriously
evaluate why you are even bothering doing such.  The salient point is
that it is absolutely illogical for volunteers to be catering to narrow
commercial interests. 
- Arguments about appeasing the needs of Enterprise distro's are moot.  
V4L-DVB owes them nothing.  Enterprise distro's are specifically that --
an enterprise's  work; if they crave support, then they can put Hans (or
whomever) on the payroll to backport for their specific needs.
- Arguments about appeasing the needs of embedded distros/platforms are
moot.   V4L-DVB owes them nothing.  Let those groups figure out and/or
support such device needs on their own; else they can put Hans (or
whomever) on the payroll.   Those manufactures releasing products within
this space will adapt to whatever V4L-DVB does.This space will not
suddenly fall apart because of our decision.   These entrepreneurs have
entered this space specifically to exploit a market opportunity.  If
they exit, someone else will move in.  Its simple free market
dynamics.   (As it is, they are getting a free lunch ... seriously, I
think that when the embedded space looks at how bent over accommodating
we currently are, they must be rubbing their hands together and
gleefully repeating Flounders statement: Oh boy, is this great!
(http://www.acmewebpages.com/midi/great.wav))

The V4L-DVB is lacking in strategic direction.  Yesterday was the time
to adopt one; so lets pick up one today!

I believe the plan to currently backport to 2.6.22 but to bump/narrow
the kernel support window to the ideal/easier_to_maintain 2.6.25, once
express support from the big 3 desktop distos ends, is the most logical
choice and the one which will have the most beneficial impact on the
project's future.



--
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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-zoran

[CityK]

Hans Verkuil wrote:

> It took me several long weekends to get all this work done, but I think it's 
> been very worthwhile.
>   

Kudos!  Well done -- another positive change! 

> Together these cards use the ... ks0127 i2c devices

quick question(s) - is this what I think it is -- a remote controller IC
?   If so, do you know who manufactures this IC?  (I'm trying to connect
the dots with the problematic ks003 and ks007 ICs found on some cards)
--
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: [linux-dvb] Can I use AVerTV Volar Black HD (A850) with Linux ?

[CityK]

Laurent Haond wrote:
> af9015_copy_firmware:
> af9015: command failed:2
> af9015: firmware copy to 2nd frontend failed, will disable it
> dvb-usb: no frontend was attached by 'AVerMedia A850'
>
> 
>
> dvbscan fails with this error : Unable to query frontend status
> and sometimes (not everytimes) dmesg shows :
> af9015: recv bulk message failed:-110
> af9013: I2C read failed reg:d417
>
>
> Tried Kaffeine, did not work either...
>   

Just as a FYI, if you haven't already realised it yourself (though I
suspect you have),  don't bother proceeding with testing with dvbscan or
kaffeine until you get the frontend to initialize (as they are doomed to
fail otherwise).


Laurent Haond wrote:
>>> af9015_copy_firmware:
>>> af9015: command failed:2
>>> af9015: firmware copy to 2nd frontend failed, will disable it
>>> dvb-usb: no frontend was attached by 'AVerMedia A850'
>>> dvb-usb: AVerMedia A850 successfully initialized and connected.
>>>   
>> No knowledge why it fails. I suspect wrong GPIO, again this is AverMedia
>> device... You should take usb-sniff and look correct GPIO from there.
>> 
>
> I trying to do that, but i'm not able  to find a recent and working
> repository for usbreplay and parser.pl
>
> Seems that http://mcentral.de/wiki/index.php5/Usbreplay is out of date,
> and that http://mcentral.de/hg/~mrec/usbreplay is no more available.
>
> Can you point me to a working repository where i can get them ?
>   

You can find a parser in the /v4l2-apps/test directory of the v4l-dvb
source  (I'm not sure why it is in the /test directory and not the
/util , hence my  concurrent message on the list, douglas' pull request,
regarding this).

--
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: [PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb/

[CityK]

Douglas Schilling Landgraf wrote:
> Hi Mauro,
>
> Please pull from http://linuxtv.org/hg/~dougsland/v4l-dvb/ for the
> following: 
>
> - v4l2-apps: Add parser for USB snoops captured from SniffUSB 2.0

It is not clear to me why this ended up in /v4l2-apps/test, as opposed
to /v4l2/util -- can someone comment? Thanks.

--
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: RFCv1: v4l-dvb development models & old kernel support

[CityK]

HI Hans,

Hans Verkuil wrote:
> Oldest supported openSUSE kernel is 2.6.22 (10.3). I don't know when the 
> end-of-life due date is for this openSUSE release. It might not be too long 
> from now. (I can't find a decent webpage with the openSUSE releases, does 
> anyone have one?)

Here's a couple of sources:
- http://en.opensuse.org/SUSE_Linux_Lifetime  ... spells out their firm
dates and projections
- http://en.opensuse.org/Roadmap  ... clicking some of the release
"product highlights" also convey the info (but the key word was "some",
as opposed to the ideal case where "all" the release product highlight
descriptions prominently convey such info)

Hopefully someone from the SUSE community will work towards making such
information both more prominently displayed and a little easier to find



--
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: [Bulk] [linux-dvb] Problem with TV card's sound (SAA7134)

[CityK]

panagiotis takis_rs wrote:
> Hey!!
>  
> I have a problem with my tv card(pinnacle pctv 310i)
> I can see image but i have no sound.
> I have tried both tvtime and kdetv.
>  
> I have found this http://ubuntuforums.org/showthread.php?t=568528 . Is it 
> related with my problem?
>  
> My tv card give audio output with this way: direct cable connection from
> tv card to sound card ( same cable witch connect cdrom and soundcard )

I didn't read through the link you provided, but it appeared to be in
regards to getting audio via DMA (using the card's 7134 chip to digitize
the audio and send it over the PCI bus to the host system).  You, on the
other hand, indicate that you are attempting to use the method of
running a patch cable between your TV card and sound card (meaning that
the sound card will do the digitizing instead).  Question:  have you
checked your audio mixer to make sure that any of the inputs are not muted?

--
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: PVR x50 corrupts ATSC 115 streams

[CityK]

Andreas wrote:
> Just to let you know that you're not alone:
> I had a simiilar problem with the combination of an AverMedia A180 and 
> two Asus Falcon (they use the ivtv drivers and firmware). Whenever one 
> of the Falcons was recording, I got blips and dropouts on the 
> AverMedia. I chalked it off to a flaky mainboard and seperated the 
> Falcons and the Avermedia in two different computers. A while later I 
> got a new mainboard and additional ATSC tuner cards. As long as I had 
> two of the ATSC tuner cards installed, the recordings were ok, except 
> for an occasional dropout. But when I put a third ATSC tuner in, the 
> recordings were barely watchable. After I put two ATSC tuners (2x 
> Avermedia A180) in a different computer, they *all* are recording 
> almost perfectly. Even a HVR-1600 card that I had dismissed as broken, 
> delivers very good recordings in the other computer.

It should be noted that a common element here in the two cases is the
Nxt2004 (demod for both the A180 and 11x cards).
--
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

Regarding development for NXP saa7160/1/2 and saa7164 ICs

[CityK]

Evidently someone from NXP has left a message in the wiki (Ignore the
incorrect date, as the message was entered today; see history for
confirmation): http://www.linuxtv.org/wiki/index.php/Talk:NXP_SAA716x

I will invite them to join into this thread.

If "octavsly" is able to assist, I believe the relevant background on
the matters are essentially:

A) SAA7160/1/2
- The current rendition of the driver that Manu has been developing 
resides here: http://jusst.de/hg/saa716x
- IIRC, Manu found that some particulars of the chip(s) were not clearly
documented within the datasheets he had been provided, so development is
still largely a WIP

B) SAA7164
- my understanding is that there was a fair amount of work towards a
driver put in by Steve, but he has had to put this project on hold
- a number of other people have expressed interest in pushing forth with
this, but I would imagine that Steve may be prevented by NDA from aiding
them in their interest

--
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: vbox cat's eye 3560 usb device

[CityK]

Hi Amy,

Amy Overmyer wrote:
> I’m trying to write a driver for the 
> device, just as a learning exercise. So far, I’ve got the firmware in intel 
> hex 
> format (from usbsnoop on windows, then a couple perl scripts to mutate it) 
> and 
> am able to use fxload to load it with –t fx2 and there are 2 separate files, 
> a 
> short one (the loader) and the firmware proper; so in fxload I have a –s and 
> a 
> –I. 
>  
> I’m able to take it from cold to 
> warm that way solely within Linux. 
>  
> The device itself has a cypress CY7C68013A fx2 chip and a large tin can 
> tuner/demod stamped with 
> Thomson that has a sticker on it identifying it as 8601A. Helpfully, the 3560 
> opens up easily with the removal of two screws on the shell.
>   

The Thomson NIM is the same one that they use on their 150/151 PCI
cards.   I don't know what the internal components of it are, but the
digital demodulator may be somewhat exposed to view -- the metal can has
a ventilation opening, though the metal may actually be bent inwards for
contact with the chip (so as to allow the casing to act as a
heatsink)).   If you can ascertain the identity of the unknown
components then you  will be  in a better position to gauge whether you
should bother continuing or not  (i.e. if the demod is currently
unsupported, you would have to develop support for it in order to ever
get the device working under Linux).  My suggestion here is:
- non-invasive: search for any clues from the Windows driver inf files
- invasive:  as non-destructively as possible, open the can ... I don't
advise this unless it looks do-able ... proceed at your own risk.

Lastly, are there any other IC components on the back or front of the
PCB ?  Can you provide pics (upload them to the wiki article)) ?

>  
> It’s cold boot usb id is 14f3:3560 and its warm boot is 
> 14f3:a560.
>  
> I have taken that hex file and 
> created a binary file out of the 2nd file (-I in fxload speak). I 
> think, correct me if I’m wrong, there is already a fx2 loader available, thus 
> I 
> will not need the loader file.
>  
> One of the stranger things I saw in 
> the usbsnoop trace in windows was when it came to reset of the CPUCS, the 
> driver 
> sent down both a poke at x0e600 and a poke at 0x7f92. One is the fx CPUCS 
> register, I believe the other is a fx2 CPUCS register. 
>  
> Currently I am mutating dibusb-mc 
> just to see if I can get it to the point of going from cold to warm in the 
> driver. 
>  
> I have taken usb sniffs from windows 
> of doing things such as scanning for channels, watching a channel, etc. so I 
> can 
> try to figure out if anything else in the v4l-dvb collection behaves 
> similarly.
>  
> I guess what I’m looking for is any 
> hints that might be useful to figuring this out. 
>  
> Like I said, it’s a learning 
> exercise, I already have enough tuners, and anyway, the cost of buying a 
> supported tuner is far cheaper than the time needed to develop 
> this!
>  
> Thanks for any info! I’ve pretty 
> much devoured everything available on the wiki.

have a look at the cxusb, its likely closer to what you want:
http://linuxtv.org/hg/v4l-dvb/file/tip/linux/drivers/media/dvb/dvb-usb/
--
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: PVR x50 corrupts ATSC 115 streams

[CityK]

Steven Toth wrote:
> Agreed, probably a secondary issue - which probably needs some
> attention regardless.
>
> I don't follow kworld products so I don't pretend to know which demod
> they're using. I guess my question to the wider audience is, do people
> with this same demod on other cards experience similar BER issues.

The KWorld 11x uses the Nxt2004 demod ... and "Zoinks!", upon checking,
I find that my single 11x card is now exhibiting BER too !   This is
something new to me, as previous femon output was always free of such
errors.
--
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] V4L: Storage class should be before const qualifier

[CityK]

Jiri Kosina wrote:
> On Mon, 16 Feb 2009, CityK wrote:
>
>   
>>>>  [inline patch] 
>>>> 
>>> This doesn't seem to be picked by anyone for current -next/-mmotm, I have
>>> applied it to trivial tree. Thanks,
>>>   
>> Will this create any complication? As it is indeed queued in our
>> patchwork: http://patchwork.kernel.org/project/linux-media/list/
>> 
>
> Hmm, patchwork ... did this land in any actual code tree? It has been 
> submitted by Tobias on 9th Feb and I was not able to find it in any tree 
> today, so I applied to to trivial tree (to which the patch has been 
> originally CCed).
>
> If you guys actually have queued in some tree, please let me know and I 
> will drop it.

I'll defer to Mauro for the absolutes, but it looks like it got applied
to V4L-DVB mainline Hg yesterday and is in Mauro's Linux-next git.
--
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: New v4l2 driver for atmel boards

[CityK]

Sedji Gaouaou wrote:
> Hi everybody,
>
> I am writing here to know if it is the proper place to send a driver
> that I have written for atmel's boards.
> I would like to know as well if there is a git tree against which I
> should based my patch or should I based it against the latest rc?

Hello, here's an overview for submissions: 
http://www.linuxtv.org/wiki/index.php/Development:_How_to_submit_patches
--
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: [Bulk] RE: New Card - BT878

[CityK]

Chris Wilson wrote:
> Howdy, thanks for all the info! :) its greatly appreciated. Thanks for all
> the background information as well. 
>
>
> This is the output from lspci -s 01:05.0 -vnn for my BT878 Card:
>
> 01:05.0 0400: 109e:036c (rev 11)
> Flags: medium devsel, IRQ 10
> Memory at fd80 (32-bit, prefetchable) [disabled] [size=4K]
> Capabilities: [44] Vital Product Data
> Capabilities: [4c] Power Management version 0
>
> I've had this card working before, the ol' noggin does'nt want to fire on
> all eight and remind me how I did it ;). 
>
> Thanks a bunch once again!

Hi Chris,

Please don't drop the mailing lists from the discussion (use your email
client's "reply all" feature) ... I have cc'ed the Linux-media list back
in. Also, in future, please don't top post.

Regarding this card, the absence of a device subsystem ID in your output
for the above command leads me to think that your card likely lacks an
EEPROM. Do you know the name of the device or is it just a generic bttv
card? (i was hoping we could have ascertained its identity from the
above command, but obviously no luck on that route).

Given that you've been able to run it under Linux before (as per your
above and previous message's statements), that is certainly encouraging.
Can you please provide the output from dmesg.

--
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] V4L: Storage class should be before const qualifier

[CityK]

Jiri Kosina wrote:
> On Mon, 9 Feb 2009, Tobias Klauser wrote:
>   
>>  [inline patch] 
>> 
>
> This doesn't seem to be picked by anyone for current -next/-mmotm, I have
> applied it to trivial tree. Thanks,

Will this create any complication? As it is indeed queued in our
patchwork: http://patchwork.kernel.org/project/linux-media/list/
--
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: firmware

[CityK]

Matthias Schwarzott  wrote:
> I don't get you. 

I was having a little fun.  My remarks contained references to Lewis
Carroll's "Alice's Adventures in Wonderland".

Nowadays, the expression "follow the rabbit" (which, stemming from
Alice's Adventures, is actually  abbreviated from the act of following
the rabbit down the hole) implies that one will discover something by
following the metaphorical rabbit (which, in this case, was the link to
wiki article on firmware, which itself  contained links to the xc3028 IC
family article).

Though perhaps not a particularly common expression, I'm sure that most
are familiar with it or have come across it in other forms and
presentations.  Pop culture, for example, has many such references --
take the movie "The Matrix", for example, in which, IIRC, the character
Morphieus invites Neo to "follow the rabbit"


> What do you want for Gentoo? checking the wiki content about firmware?

Gentoo is, typically, not associated as a beginners distro.  It,
generally speaking, requires or, at the very least,  affords the user
the opportunity to become more familiar with the underlining
architecture and mechanics of the OS.  One might be tempted to call that
a discovery process.

Hence, when a Gentoo user like Michele states that they require a
firmware entitled "xc3028L-v36.fw", I'm (rightly or wrongly) making an
implicit assumption that they would be perceptive enough to make the
relevant connection(s) and press forth when presented with a
metaphorical rabbit.
--
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: [linux-dvb] A dvb-core code problem

[CityK]

Zhang Xiaobing wrote:
> I found a code problem in dvb-core when I was debugging with my dvb
> driver.
>
> The code in dvb_dvr_release() file dmxdev.c
> /* TODO */
> dvbdev->users--;
> if(*dvbdev->users== -1* && dmxdev->exit==1) {
> fops_put(file->f_op);
> file->f_op = NULL;
> mutex_unlock(&dmxdev->mutex);
>
> "dvbdev->users== -1" should be changed to "dvbdev->users== 1",
> otherwise driver may block forever in dvb_dmxdev_release() where a
> wakeup condition is "dvbdev->users== 1".
>
> Here is the code in dvb_dmxdev_release().
>
> if (dmxdev->dvr_dvbdev->users > 1) {
> wait_event(dmxdev->dvr_dvbdev->wait_queue,
> *dmxdev->dvr_dvbdev->users==1*);
> }
>
> I hope it is right to post this message here.

Hi Zhang,  could you post a patch to the linux-media mail list; for
general info see here:
http://www.linuxtv.org/wiki/index.php/Development:_How_to_submit_patches


--
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: ImpactVCB 64405 low-profile PCI problem

[CityK]

Eric Schwartz wrote:
> Hi all,
>
> I'm having a frustrating problem with getting a brand new Hauppauge card
> to work with v4l, of the ImpactVCB 64405 low-profile PCI variety. I have
> a basic NTSC camera that I want to hook up to one of the composite
> inputs. And yes, during my troubleshooting efforts I succumbed to the
> temptation of plugging it into an XP box (gasp!) and verified that the
> hardware works perfectly fine.
>
> Vanilla kernel versions 2.6.21, 2.6.24, and 2.6.28 all detect the
> presence of the card and painlessly load the bttv module. According to
> dmesg, it audodetects the type of card and even reads the exact model
> string off the eeprom. (see dmesg output pasted below)
>
> So far so good, eh? When I plug the camera into each of the inputs, I
> get nothing on /dev/video0. Not exactly all zeroes, to be precise, but
> close. A hexdump shows that there are occasional "c0"s mixed in with the
> "00"s. Using "dov4l -i" lets me change the inputs as expected -- no
> errors when the input number is in range, error when it's > 3.
>
> Searching Google, I found that some people extracted firmware from a
> Windows driver for a similar card and passed the "firm_altera=fwfile"
> parameter to modprobe. I got the firmware file in question (from another
> driver disk; it wasn't on the one that came with the card) but the
> module balks at accepting that parameter at all. (bttv: Unknown
> parameter firm_altera)
>
> Anyone have experience with getting this card to work? What I thought
> was going to be an easy project has quickly turned into a nightmare. Any
> help will be appreciated.
>
> Thanks,
> Eric Schwartz
>
> --
>
> sunset:~# dmesg | grep bttv
> bttv: driver version 0.9.17 loaded
> bttv: using 8 buffers with 2080k (520 pages) each for capture
> bttv: Bt8xx card found (0).
> bttv :02:0a.0: PCI INT A -> Link[LNKD] -> GSI 11 (level, low) -> IRQ 11
> bttv0: Bt878 (rev 17) at :02:0a.0, irq: 11, latency: 64, mmio:
> 0xf6001000
> bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb
> bttv0: using: Hauppauge (bt878) [card=10,autodetected]
> bttv0: gpio: en=, out= in=00ff [init]
> bttv0: Hauppauge/Voodoo msp34xx: reset line init [5]
> bttv0: Hauppauge eeprom indicates model#64405
> bttv0: tuner absent
> bttv0: i2c: checking for MSP34xx @ 0x80... not found
> bttv0: i2c: checking for TDA9875 @ 0xb0... not found
> bttv0: i2c: checking for TDA7432 @ 0x8a... not found
> bttv0: registered device video0
> bttv0: registered device vbi0
> bttv0: PLL: 28636363 => 35468950 .. ok
>
> --

I don't know the device, but I don't think it requires a firmware -- from the 
pic on Hauppauge's website, it looks to be a plain jane bt878 card 
(http://www.hauppauge.com/site/products/data_impactvcb.html).

I do notice that there are two entries in the bttv cardlist 
(http://linuxtv.org/hg/v4l-dvb/file/tip/linux/Documentation/video4linux/CARDLIST.bttv)
 for that particular subsystem ID, a rather generic Hauppauge entry for card 10 
(which your device is apparently being autodetected as) and what looks to be 
the actual specific entry for your device, card 143.

Try using the later card number (in your relevant modprobe config file or via 
command line loading) and see if that has any impact.


--
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: Sony PlayTV (PS3)

[CityK]

Vigasoco SDL wrote:
> Quick and dirty patch por Sony PlayTV (Playstation 3 DVB-T)
>   

Hi, please see
http://www.linuxtv.org/wiki/index.php/Development:_How_to_submit_patches
--
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: [linux-dvb] DViCO FusionHDTV7 Dual Express

[CityK]

Tim Lucas wrote:
> My cable system was recently updated to time warner so I thought I
> would try to get the mythbuntu box working again.  
> I have the DViCO FusionHDTV7 Dual Express card which seems to be
> recognized by my system but I still cannot tune channels. I tried
> using tvtime and got the following error
>
> I/O error : Permission denied
> Cannot change owner of /home/lucas/.tvtime/tvtime.xml: Permission denied.
> videoinput: Cannot open capture device /dev/video0: No such file or
> directory.

Analog is currently not supported by the cx23885 driver
--
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: firmware

[CityK]

Devin Heitmueller wrote:
> CityK,
>
> That actually wasn't a very helpful link you sent ... the page on the XC3028 
> and XC2028 pointed to on
> that page makes no reference to getting the firmware for the low power 
> version of the chip.
>
> Michele,
>
> You can get the firmware here:
>
> http://steventoth.net/linux/hvr1400/xc3028L-v36.fw
>   

My apologies, I first off, didn't notice the low power chip, and, in any
regard, even if I had, I was under the impression that it was documented
there.  I will amend that shortly.

Devin Heitmueller wrote:
> On Sun, Feb 15, 2009 at 3:38 PM, CityK  wrote:
>>> Michele wrote:
>>>   
>>>> my gentoo system ... I need a firmware called "xc3028L-v36.fw"
>>> Follow the rabbit: http://www.linuxtv.org/wiki/index.php/Firmware
>>>
>>>   
> CityK,
> That actually wasn't a very helpful link you sent ... The user would
> have to know he has a Xceive 3028L tuner, and even if he had been able
> to figure that out, 
>   

I would hope that someone using Gentoo (hardly a hands off distro) would
be sharp enough to know how to follow the rabbit down the hole  ...
although I'd advise that they avoid sipping from any vessel labelled
with the words "Drink Me"
--
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: firmware

[CityK]

Michele wrote:
> Hi,
> I'm new here and i'm trying TM6061 driver from your repo. Actually I'm now 
> able to make the module tm6000 and I find my card (wintv-hvr-900h) as card 9.
> But when today for the first time my gentoo system recognize it I discovered 
> that I need a firmware called "xc3028L-v36.fw".
>  I searched a while over the net and it seems to be in vendor CD but it 
> isn't, 
> even downloading drivers from webpage I find a sys file but it is not 
> tridvid.sys, it is called hcw66xxx.sys (and also it seems to be a 64bit 
> version called  hcw66x64.sys). I tried both of them but nothing happend, I 
> also try to find that file over internet but everytime file checks fail. 
> Someone have some suggestion about where to find it?
>   

Follow the rabbit: http://www.linuxtv.org/wiki/index.php/Firmware
--
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: [ANNOUNCE] V4L, DVB and Maintainers Mailing Lists at vger.kernel.org

[CityK]

Mauro Carvalho Chehab wrote:
> There are a few archives already available, at:
>
> * http://dir.gmane.org/gmane.linux.drivers.video-input-infrastructure
> * http://www.spinics.net/lists/linux-media/
> * http://www.mail-archive.com/linux-media@vger.kernel.org
>
>   
Hi Mauro,

when you get a free moment, can you have MARC added to the list of
archive sites: http://marc.info/?q=about#Add

Thanks
--
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: KWorld ATSC 115 all static

[CityK]

hermann pitton wrote:
> Am Dienstag, den 03.02.2009, 01:03 -0500 schrieb CityK:
>   
>> - Mauro created a patch intended to be applied against mainline ... I
>> tested and analog tv did NOT work
>> 
>
> strange, that we don't see at least some error messages.
>   

Indeed, on a quick glance, the output looks entirely indifferent

hermann pitton wrote:
> I had a quick test on the in kernel radeon driver on Fedora 10 and
> recent 2.6.27 with xawtv-3.95.
> True is, that overlay-preview yields dga is not supported, but with
> current v4l-dvb master and Hans' conversions mmap/grabdisplay works with
> the old "xawtv -v 1 -nodga -remote -c /dev/video2" something.
>   
Yep, as I menitoned: 
http://www.mail-archive.com/linux-media@vger.kernel.org/msg00989.html. 
In regards the hit and miss functionality I mentioned with kdetv, the
pattern was simple:  grabdisplay v4l1 mode would work only after having
just used tvtime.  Similarly, in the v4l2 mode, after having just used
tvtime, one can observe a momentary flicker of video (i.e. lasting only
a few hundredths of a second) from a channel before it reverted to all
static.

Additionally, when the apps fail in overlay mode, and are displaying all
static, you can actually simultaneously open up one of the digital apps
(take your pick; kaffeine, MPlayer...) and successfully watch dvb.

hermann pitton wrote:
> Like you, I can't imagine that the earlier Kworld ATSC 110/15
> initialization in Hans' kworld repo could be related to it.
>   

No, no -- Mauro doubts it.  I,  on the other hand, suspect that there
has been something innocuous introduced  within the new v4l2 framework
that is causing this.

hermann pitton wrote:
> I can test on nv drivers as well next, they might have dropped support for it 
> too and just the x capabilies should be reported.

Nope -- as I mentioned, dropping back to a snapshot from roughly 3 weeks
ago and applying Mike's patch works with both the nv and nvidia driver,
hence disproving that it is anything X related. 


>> - Mainline v4l-dvb:
>> Pros: none ... you will achieve this thread's namesake -- all static.
>> Cons: since the code from Hans' v4l-dvb-saa7134 repo was merged, Mike's
>> hack/workaround patch has been rendered ineffective for good. Mauro's
>> later patch was also pulled into mainline, but it does not change the
>> situation analog tv (and I do not mean in relation to Mike's patch, I
>> mean precisely upon its own).
>>
>> - Mike's hack/workaround patch
>> Pros: it will apply and work with snapshots of v4l-dvb up to probably ~
>> Jan 15th or so. All the apps that I tested with work as expected.
>> Cons: in order to use analog tv, upon each boot, one must do what I
>> termed being a dance with unloading and reloading the tuner module via
>> modprobe.
>> 
>
> I'm not sure if we even have the status of all devices potentially
> seeing impacts, but reloading modules becomes more difficult, since we
> load now saa7134-alsa by default. This will cause that apps like mixers
> on runlevel 5 need to be closed before you can unload/reload
> saa7134-alsa and saa7134 and then further any tuner modules.
>
> This is fine for all the cards without such problems, but else one must
> be aware off. With "options saa7134 alsa=0" the old behaviour is
> restored.
>
> Mauro also disabled saa7134-alsa support on saa7130 devices, which
> simply do not support it and the deprecated saa7134-oss. Thanks! 
>   

And speaking of alsa:

CityK wrote (Jan 19th):
> Some Other Miscellanea:
>
> 2) This is likely related to the discussion about the gate -- after
> closing the analog TV app, the audio from the last channel being viewed
> can still be heard if one turns up the volume on their system.  This
> leakage has always been present.  But given that we are addressing this
> issue now, it strikes me that the gate is being kept open on the audio
> line after application closing/release occurs.
>   

This issue seems to have been resolved since having updated to the ALSA
1.0.19 release from a couple of weeks ago (which literally contained a
zillion fixes, so I'm not going to bother trying to figure out which one
might have been the fix).. 



--
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: KWorld ATSC 115 all static

[CityK]

David Engel wrote:
> I never received received anythin after Jan. 18 and couldn't find
> anything in the archives.  Strange.
>   

hermann pitton wrote:
> Am Dienstag, den 03.02.2009, 01:03 -0500 schrieb CityK:
>> - On Sunday Jan 25th I sent a lengthy message to the list... I went to the 
>> mailing list archive to
>> find a link for my message...only to discover it was NEVER 
>> achieved/recordedgr. So I'm at a complete loss as to who actually 
>> saw the Jan 25th message and who didn't.
>> 
>
> On Jan. 18 the copy to the video4linux-list was dropped.
> Some mailers by default have a limit there and the number of recipients
> must be increased manually, i don't think it was intentionally.
>
> However, all on linux-media should have received your postings and they
> are in the archives.
> http://www.spinics.net/lists/linux-media/msg00817.html
>   

LOL -- that's hilarious; I had checked both
http://www.mail-archive.com/linux-media@vger.kernel.org/thrd5.html#01125
and
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/203/focus=42489
and couldn't find it, so I didn't bother looking for it on spinics.
(Personally, I prefer neither of the 3 above archives, rather, I like
Marc, which I don't believe we've contacted yet ... I will bug Mauro
about this in a minute). I had figured that it might have been a
limitation with the message size. Anyway, good to know that the Jan 25th
message made its way to at least one archive.

>> - Further, somewhat concurrently, I discovered that (with Hans' kworld
>> test repo) analog TV was ONLY working with tvtime ... xawtv/motv and
>> kdetv were borked (I don't use Myth, so I have no idea what its status
>> would be ... though, I'd suspect that it works like tvtime).
>> 
>
> I will try it with MythTV.

Thanks David.

--
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: KWorld ATSC 115 all static ... Mike's clarification

[CityK]

CityK wrote:
> CityK wrote:
>   
>> Hans wrote:
>> 
>>> CityK wrote:
>>> 
>>>   
>>>> In regards to the tuner type being set twice, that is precisely my point
>>>> -- its peculiar and not symptomatic of normal behaviour.  That is why I
>>>> asked whether you expected it to do this
>>>>   
>>>> 
>>> I think it is OK. The second setup is probably done by dvb_attach() in 
>>> saa7134-dvb.c, line 1191. Can you verify that with a debug message?  
>>> 
>>>   
>> Could not verify.  (dmesg output provided below at end).
>>   
>> 
>
> Actually, looking at the dmesg output now, it is apparent that you are
> correct:
>
> dvb_init() allocating 1 frontend
>
> So, its a case of a bit of redundancy now.

Michael Krufky wrote:
> CityK wrote:
>> - Hans' second attempt at this is found in his v4l-dvb-kworld test
>> repo... testing this code revealed that analog tv did indeed work
>> again withtvtime ... I also noted that there seems to be a bit of
>> redundancy nowin terms of the tuner being initialized twice
>>
>> ... [snip]...
>>
>> - Hans kworld repo:
>> Pros: does provide analog tv functionality for, at a minimum, tvtime.
>> Cons: The changes introduced result in, as testing to date has shown, a
>> harmless bit of duplication in the way of the tuner being loaded twice.
>> kdetv/motv/xawtv, at a minimum, do not work in overlay mode.  
>
> Tuner is _not_ loaded twice.  The tuner-simple driver is displaying
> itself twice in the dmesg logs, because it is attached twice. 

I actually knew that, but as a consequence of writing a long reply, late
at night, I wasn't fully coherent in my faculties and ended up
misreporting the case.

> Once for analog, again for digital -- this is *by design*.
>
> The old code used dvb-pll for the digital side, and tuner-simple for
> analog.  The common support within those two modules has been merged
> together to remove redundancy and allow us to share state between the
> two instances of the driver for the same part.
>
> As tuner-simple registers each side of the interface, it will display
> a message to the kernel logs indicating what tuner has been attached
> -- this is what you see twice.

Mike, thanks for the clarification that the behaviour is intended by
design. And looking at the events in conjunction with the above
explanation, it all makes sense:

tuner 1-0061: chip found @ 0xc2 (saa7133[0])
tuner-simple 1-0061: creating new instance
tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual in)
saa7133[0]: registered device video0 [v4l2]
saa7133[0]: registered device vbi0
dvb_init() allocating 1 frontend
nxt200x: NXT2004 Detected
tuner-simple 1-0061: attaching existing instance
tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual in)

 
hermann pitton wrote:
> For the second attach of hybrid tuners in digital mode we maybe should print 
> something
> pointing to it.
>   

Yes, I agree -- adding something simple to the existing message here
might help any future cases of head-scratching by those less
knowledgeable of the intricacies.
--
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: KWorld ATSC 115 all static

[CityK]

David Engel wrote:
> As far as I can tell, this thread petered out without a resolution.  
> CityK later posted on avsforum, however, that analog on his card was
> after more changes by Hans.  I'm confused.  Is analog on the KWorld
> 115 supposed to be working again or not?  I saw that some changes by
> Hans made it into the main Hg repository, but as of yesterday, analog
> still didn't work for me.
>   

Nope, this thread is still alive and well -- I posted to it last Thurs
(?), and Mauro replied, but I haven't had time to follow up with this
since then. Anyway, here's a synopsis of the situation:

- Hans had a first go at the saa7134 (and related modules) in this work
was in his v4l-dvb-saa7134 test repo  these initial changes,
unfortunately, were NOT sufficient on their own to get analog TV
working. These changes did, however, get pulled into the mainline of v4l-dvb

- Hans' second attempt at this is found in his v4l-dvb-kworld test repo
... testing this code revealed that analog tv did indeed work again with
tvtime ... I also noted that there seems to be a bit of redundancy now
in terms of the tuner being initialized twice

- Mauro created a patch intended to be applied against mainline ... I
tested and analog tv did NOT work

- On Sunday Jan 25th I sent a lengthy message to the list, outlining
some debug results etc. and also informing Mauro that his patch did NOT
work ... I know that, at the very least, Trent and Hermann received that
message, because they quoted from it in further discussion about the i2c
gate (the inherent underlying problem at the heart of the issue).

- A few days later, scanning through the #irc logs, I caught a
discussion, regarding Mauro's patch getting pulled into mainline, and
the discussion seemed to indicate that there was some confusion as to
what I had said worked and what doesn't. This surprised me for I had
been pretty explicit in my Jan 25th mail list message. The other
alternative was perhaps they simply had missed that message...so, in
order to clear the situation up, I went to the mailing list archive to
find a link for my message...only to discover it was NEVER
achieved/recordedgr. So I'm at a complete loss as to who
actually saw the Jan 25th message and who didn't.

- Further, somewhat concurrently, I discovered that (with Hans' kworld
test repo) analog TV was ONLY working with tvtime ... xawtv/motv and
kdetv were borked (I don't use Myth, so I have no idea what its status
would be ... though, I'd suspect that it works like tvtime). I quickly
traced this problem to be related to dga and Xv. A very similar
situation with these apps existed several years ago when the proprietary
X drivers from nvidia and ati removed dga functionality from their
respective drivers (for some background read:
http://www.nvnews.net/vbulletin/showthread.php?t=68232, and also the
relevant portion of the FAQ from the nvidia readme:
ftp://download.nvidia.com/XFree86/Linux-x86_64/180.27/README/chapter-07.html),
however, the basic nv driver would still function. Nvidia would later
provide a workaround to this issue in their driver.
So, in this modern day occurrence of this similar error/bug, the obvious
first test is to eliminate the proprietary driver from the equation.
However, the test result with the nv driver was the same -- borked
motv/xawtv and kdetv. I reported this, saying that I suspected that a
something may have been introduced somewhere resulting in this issue
with these apps resurfacing. This is why I asked that Hans' kworld repo
NOT be pulled into mainline (if there had been any thought to that --
though I don't think there was, because I now realize that I don't think
many had even seen my prior Jan 25th message !) until further testing
was performed.

- Mauro replied believing that this was unrelated to anything v4l-dvb,
but rather an artefact of the X drivers. I suspected that that was NOT
the case (the nv driver failing in my previous test was my cue). The
next obvious test was to revert back to an older v4l-dvb snapshot that
was patched with Mike Krufky's hack/workaround.

[reverting back should have been an easy task, but unfortunately I
managed to turn it into a frustrating ordeal --- in the case of Hans'
kworld source, the rminstall process did not blow away all the modules;
further, while I had been testing channel scans with xawtv/motv/kdetv, I
also tried with YAST, and unbeknownst to me, it must have saved an
attempt at configing the ir remote --- so that, later, when no v4l-dvb
modules were any longer present on the system, a config script somewhere
must have been calling for the related remote control i2c-blah-blah-blah
modules and the system would freeze, all too coincidently just when the
nvidia x driver was starting up X ... and booting to failsafe and
console mode was not working either (or at least not very well) ... so
my initial belief tha

Re: KWorld ATSC 115 all static

[CityK]

CityK wrote:
> Hans Verkuil wrote:
>   
>> I've made a new tree http://linuxtv.org/hg/~hverkuil/v4l-dvb-kworld/ 
>> that calls 'enables the tuner' before loading the module. See if that 
>> works.
>>
>> ...
>>   
>> I suspect that this might fix the bug.
>> 
>
> Hans,
>
> ...  it works !!  

I may have found a problem (tvtime works perfectly; other analogue apps
like xawtv/motv, kdetv ... are not working properly now -- you can do a
channel scan with them and everything_appears_to work as expected (i.e.
channels are found and are displayed/played correctly during the scan),
BUT as soon as you actually go to use the app, it does not work
(static).  It appears that the issue is related to dga and Xv (as
passing the -nodga -noxv options with xawtv/motv actually works ...
kdetv is hit and miss -- sometimes the v4l1 mode works, other times it
doesn't (likely a pattern there but haven't found it yet), but v4l2
plugin does NOT work at all (static)).  In addition, the nvidia driver
is NOT the source of the error, as the same occurs under the nv driver
as well. 

Will have to do another test to confirm whether this error was
introduced in the KWorld repo.  Consequently:

> Mauro Carvalho Chehab wrote:
>   
>> Hans Verkuil wrote:
>> 
>>> Note that Mauro merged my saa7134 changes, so these are now in the master 
>>> repository.
>>> 
>>>   
>> Yes. We need to fix it asap, to avoid regressions. It is time to review also
>> the other codes that are touching on i2c gates at _init2().
>>   
>> 
>
> Thoughts on merging the changes from Hans' KWorld repo? 

If there were any thoughts on this, please put them on hold until I can
test further. 
--
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: KWorld ATSC 115 all static

[CityK]

hermann pitton wrote:
> Am Sonntag, den 25.01.2009, 13:49 -0800 schrieb Trent Piepho:
>   
>> On Sun, 25 Jan 2009, CityK wrote:
>> 
>>> Hans Verkuil wrote:
>>>
>>> this still begs Han's question: "how do you manage to make analog TV
>>> work if the tda9887 isn't found? That's rather peculiar." I don't have
>>> an answer for that. The tuner-simple module, however, seems to be able to 
>>> drive/provide that functionality sufficiently enough. 
>>>
>> The tda9887 is a simple device with just three registers.  If they are set
>> to the right value when the driver loads, which wouldn't be unexpected,
>> then it isn't necessary to actually do anything to the chip.  If you had a
>> multistandard tuner (and had access to broadcasts in multiple standards!)
>> then I expect switching standards wouldn't work without the tda9887 driver.
>> Verifying both TV and radio tuning works is probably the most realistic way
>> to check.
>> 
>
> For radio you need a tda9887 and working i2c for what i can know.
>
> Also after a cold boot the tda988x is not in a usable state for any tv
> standard yet, it needs to be set by i2c first.
>
> But for NTSC, and only NTSC, one pin can be strapped, IIRC, and then it
> works without any i2c programming needed. Guess it is a tda9885 here.
>
>   

Looks like that this is the case, as described by Trent, that is
occurring. Herman, is there any difference between the tda9885 and
tda887, as I'm pretty sure this is the tda9887 package outlined on page
52 of the tda9887 datasheet.

Alas, as being exposed to just NTSC broadcasts, not able to test on the
multistandard ;)

As for the FM radio, I know that some have mentioned the possibility for
that with this device, but I don't think anyone ever has succeeded (not
surprising given the i2c situation) and so the assumption was made,
rightly or wrongly, that it is not present. I would be amused if FM
radio support could be realised for the device.

>>>> saa7133[1]: i2c xfer: < c2 30 90 >
>>>> saa7134[3]: i2c xfer: < c2 >
>>>> saa7134[3]: i2c xfer: < c2 0b dc 9c 60 >
>>>> saa7134[3]: i2c xfer: < c2 0b dc 86 54 >
>>>>
>>>> Exactly here, when the buffers are sent the second time the tda9887
>>>> becomes the first time visible on the bus. According to Hartmut the
>>>> modification of buffer[3] from 0x60 to 0x54 is that hidden switch,
>>>> IIRC.
>>>>
>>>> 
>>> I believe Mauro is correct in regards to the tda9887 in that, within the
>>> Philips TUV1236D NIM, it is behind the Nxt2004's i2c gate.  After
>>> re-reading what Michael mentioned previously:
>>>   
>> Address 0xc2 is the PLL, not the NXT2004.  Why would the PLL control an I2C
>> gate on the nxt2004?  I think what I said before about a gpio line on the
>> PLL being used to hold the analog demod in reset when not in use is more
>> likely to be correct.
>> 
>
> That the analog demod is enabled from the pll in case of the FMD1216ME
> MK3 hybrid is what Hartmut told us.
>
> To remeber, the Pinnacle 300i hybrid with mt32xx (3250) disables the
> analog demod with tda9887 port2=0 in digital mode. That is why Gerd
> re-enables it on exit of DVB. 
>
>>> The i2c command to enable the tuner is sent to nxt200x. If there are any
>>> ATSC110 variant with a different demod (maybe a different version of 
>>> nxt200x?),
>>> then the users may experience different behaviors.
>>>   
>> That command sequence is sent to the PLL, not the nxt2004, so this is 
>> wrong.  There is another command sent to the nxt2004 (which is at address
>> 0x0a) from code in saa7134-cards.c to "enables tuner" as well.
>> 



--
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: [linux-dvb] Tuning a pvrusb2 device. Every attempt has failed.

[CityK]

Andy Walls wrote:
> blah blah blah

^ What Andy wrote ... I had not seen his reply until after sending my
own,  which evidently largely contains pretty much the same set of
answers as the former.
--
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: [linux-dvb] Tuning a pvrusb2 device. Every attempt has failed.

[CityK]

A. F. Cano wrote:
> Yes.  The RF input is hooked up to an 11ft Winegard roof antenna, mounted on
> a stand behind me, properly oriented according to antennaweb.com for the
> local stations, and with a UHF pre-amp for good measure.  It is inside, but
> a foot below the reasonably high ceiling, so it doesn't interfere with moving
> around.  With this setup I have succeeded in receiving barely visible
> analog channels when the Creator is set up as a v4l device using /dev/video0.
> Yes, the reception sucks, but I want to make sure that it is not something
> more fundamental before I go to the trouble of mounting the antenna on the
> roof.
>   

Okay. One suggestion I have here is taking the pre-amp out of the chain
right now, and just test with as basic a setup as possible.

> I'm not sure how to change the cable vs. ota setting.  Doesn't the digital
> tuner determine what it is plugged into?  

Sorry, what I was getting at was the case of user error where one might
be trying to use 8VSB for the scanning on a digital cable connection, as
opposed to using the correct modulation scheme (QAM256). So, for
example, using scan in conjunction with
"us-ATSC-center-frequencies-8VSB" as opposed to
"us-Cable-Standard-center-frequencies-QAM256". Had that been the case,
it could explain the results you observed with scan. However, as you
confirmed above, that was not the case.

In regards to the determination of what is plugged in -- no, the tuner
is a dumb component. It only does what its told. In other words,
whatever piece of software you are trying to drive it by has to state
that it wants the device to use cable or OTA; as precisely illustrated
by the example with the scan utility.

> As far as mythtv, it thinks the
> attached device is a DVB/DTV receiver.  

I'd step back from testing with Myth right now -- it adds to much of
extra layer of complexity and sources for further error. In terms of
just testing to make sure that the device is working correctly, just
stick with the basic apps for the time being (scan, azap, mplayer,
femon)

> Kaffeine has been told to use the
> us ATSC frequencies, with the results I pointed out earlier. 
>   
I haven't taken the opportunity to ever use Kaffeine for scanning OTA
just yet, however, I do note that it produces similar results for me, as
to what you observed, when I scan on digital cable using QAM256. In my
case, it repeatedly borks at 61%. I spoke with Mkrufky this morning
about Kaffeine's ATSC scanning abilities and he described it as being
less then favourablethis was actually a surprise to me, as I thought
that OTA scanning was fine. I know Devin added this support so perhaps
he could comment upon the capabilities. I also know that Devin does not
have cable, so I am not surprised to see, in my case, scans of digital
cable failing.

Reviewing your prior message, I'd suspect that dvbtune just doesn't have
support for ATSC. As you note, the other stuff is for analog.

The fact that you have the device node created and the populated by the
character devices, along with the femon result is encouraging.
Similarly, that scan is detecting something on several frequencies (just
not enough to capture any info for it) is also encouraging. I suspect
that it comes down to a case of the antenna/cable configuration ... as
noted before, take the amp out of the chain and retry ... also, if
possible, can you obtain a signal under Windows?


--
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: [linux-dvb] Tuning a pvrusb2 device. Every attempt has failed.

[CityK]

A. F. Cano wrote:
> Still trying to get the OnAir Creator to work.  It is properly recognized
> by the pvrusb2 driver, but I can't seem to get any further.  I'm now
> trying to scan the digital channels.
>   

While you seem to be trying to scan for OTA channels, I would like
confirmation that this is indeed the case of what you are attempting, as
opposed to searching for digital cable channels.

> Can anyone suggest other tools I might have missed?  Explain why I'm getting
> the results above? Since both mythtv and kaffeine find some channels in the
> scan, shouldn't I be able to watch them?  To narrow down the problem, I was
> going to tune the card to one of the channels and then use mplayer to read
> directly from the device, but I can't even change the channel.

If you are mistakenly searching for digital cable channels using the OTA
settings, that would explain a number of the observations you have
described.
--
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: KWorld ATSC 115 all static

[CityK]

CityK wrote:
> Hans wrote:
>> CityK wrote:
>> 
>>> In regards to the tuner type being set twice, that is precisely my point
>>> -- its peculiar and not symptomatic of normal behaviour.  That is why I
>>> asked whether you expected it to do this
>>>   
>> I think it is OK. The second setup is probably done by dvb_attach() in 
>> saa7134-dvb.c, line 1191. Can you verify that with a debug message?  
>> 
> Could not verify.  (dmesg output provided below at end).
>   

Actually, looking at the dmesg output now, it is apparent that you are
correct:

dvb_init() allocating 1 frontend

So, its a case of a bit of redundancy now.
--
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: Analog TV on Leadtek PxDVR 3200 H

[CityK]

Martin Edlman wrote:
> Hello,
>
> I have a problem with module cx23885, it doesn't create the /dev/video0 
> device.
>   

The module doesn't support analogue 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: [linux-dvb] supported dual tunner ATSC cards

[CityK]

Timothy D. Lenz wrote:
> Building a new VDR system for my dad that can use the newer nvida cards for 
> HD and would like to know what the choices are for ATSC
> cards with at least 2 ATSC tunners and have linux drivers. I know about the 
> HDHomerun, but that is an external device which he
> really doesn't have room for where it will be set up and it's not directly 
> supported by vdr yet. There is an IPTV plugin that
> "should" work, but as far as I know, that is untested with the hdhome run.
>
> I am loking at both PCI and PCIe cards for this.
>   

Your choices are limited. Pls see:
http://www.linuxtv.org/wiki/index.php/ATSC_Devices
--
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: KWorld ATSC 115 all static

[CityK]

Hans Verkuil wrote:
> On Sunday 18 January 2009 22:20:30 CityK wrote:
>   
>> The output of dmesg is interesting (two times tuner simple initiating):
> Shouldn't there be a tda9887 as well? It's what the card config says, but
> I'm not sure whether that is correct.
>  
>   
>> Would you like to see the results of after enabling 12c_scan to see what
>> is going on, or is this the behaviour you expected?
>> 
>
> It seems to be OK, although I find it a bit peculiar that the tuner type
> is set twice. Or does that have to do with it being a hybrid tuner, perhaps?
>   

The Philips TUV1236D NIM does indeed use a tda9887  (I know, because I
was the one who discovered this some four years ago (pats self on
head)).  But the module is not loading.  I can make it load, just as
Hermann demonstrated to Mike in one of the recent messages for this thread.

In regards to the tuner type being set twice, that is precisely my point
-- its peculiar and not symptomatic of normal behaviour.  That is why I
asked whether you expected it to do this

>> Some Other Miscellanea:
>> 1) Before this gets merged, can I ask you to also make one small change
>> to tuner-simple; specifically, swap the contents of lines 301 and 304.  
>> This will change the driver's default behaviour in regards to the
>> selection of which RF input to use for digital cable and digital
>> over-the-air.  Currently, the driver is set to use digital OTA on the
>> top RF input and digital cable on the lower RF input spigot.  However,
>> IMO, a more logical/convenient configuration is to have the digital
>> cable input be handled by the top RF input spigot, as this is the same
>> one that the analog cable is also drawn from by default. Mike had made
>> this change, on my request, previously, but it appears that it got
>> reverted after the tuner re-factoring. 
>>
>> Note:  users have reported different default configurations in the past
>> (e.g. http://www.mythtv.org/wiki/Kworld_ATSC_110), but I actually doubt
>> that there has been any manufacturing difference with the TUV1236D. 
>> Rather, I suspect that the user experiences being reported are just
>> reflecting a combination of the different states of how our driver
>> behaved in the past and differences in driver version that they may have
>> been using (i.e. that version provided by/within their distro or by our
>> Hg).  After all, this configuration setting has gone from being handled
>> by saa7134-dvb.c to dvb-pll.c to tuner-simple.c, with changes in the
>> behaviour implemented along the way.
>>
>> 
>
> I'm not going to merge this, it's just a quick hack for this card. This
> is something for Mike or Hermann to fix. 

Fair enough -- I will pester them a la Bart Simpson spy camera style
(see:
http://peanutbutterandpickles.blogspot.com/2008/06/wheres-my-spy-camera-wheres-my-spy.html
and for actual dialogue: http://www.snpp.com/episodes/7G10.html)  :P

It is a trivial change which I can vouch that works (after successfully
testing your new "KWorld" changeset, I immediately applied this change
and rebuilt ... with, of course, successful results).


> Someone with a better knowledge
> of this driver and these tuners should review the saa7134_board_init2()
> function and move the opening of tuner gate/muxes to a separate function.
>   
>> 2) This is likely related to the discussion about the gate -- after
>> closing the analog TV app, the audio from the last channel being viewed
>> can still be heard if one turns up the volume on their system.  This
>> leakage has always been present.  But given that we are addressing this
>> issue now, it strikes me that the gate is being kept open on the audio
>> line after application closing/release occurs.
>> 

I just did some testing in regards to point number 2 ... at first I was
thinking that maybe it was because tda9887 is not loading automatically
that, absent of fine control, the audio leakage was occurring.  But
after loading tda9887 and then removing the module, the leakage
continues.  Naturally, the other suspect is saa7134.  And, as it turns
out, if one modprobe -r saa7134-dvb (which obviously uses sa7134), then
the audio leakage immediately comes to an end, and checking lsmod,
saa7134 is no longer found.  So at least I know the source of the bug
now ... now its just a case of getting it to release properly.  Comments
from anyone on this?

>> 3) there is an issue about having two of these cards in the same system
>> --- IIRC, only one card will get /dev/video  Mauro touched upon this
>> very briefly in one of the earlier messages; recall:
>>
>> Mauro wrote:
>> 
>>> This generated lots of is

Re: KWorld ATSC 115 all static

[CityK]

Hans Verkuil wrote:
> On Sunday 18 January 2009 19:10:16 CityK wrote:
>   
>> merging Hans' code eliminates the usability of Mike's "hack/workaround" ... 
>> in essence, analog TV
>> function has now been completely killed with these boards.
>> 
>
> I've made a new tree http://linuxtv.org/hg/~hverkuil/v4l-dvb-kworld/ 
> that calls 'enables the tuner' before loading the module. See if that 
> works.
>
> ...
>   
> I suspect that this might fix the bug.

Hans,

Between the time of my last message and now, your title has made a turn
for the better.  I proclaim that you are no longer "Hans-the-Destroyer",
rather you should be upheld as "Hans-the-Enabler" !!

In other words, it works !!  (across reboots etc etc).

The output of dmesg is interesting (two times tuner simple initiating):

> saa7130/34: v4l2 driver version 0.2.14 loaded
> ACPI: PCI Interrupt :00:09.0[A] -> GSI 19 (level, low) -> IRQ 19
> saa7133[0]: found at :00:09.0, rev: 240, irq: 19, latency: 32,
> mmio: 0xfa021000
> saa7133[0]: subsystem: 17de:7350, board: Kworld ATSC110/115
> [card=90,autodetected]
> saa7133[0]: board init: gpio is 100
> saa7133[0]: i2c eeprom 00: de 17 50 73 ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> tuner 1-0061: chip found @ 0xc2 (saa7133[0])
> tuner-simple 1-0061: creating new instance
> tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual in)
> saa7133[0]: registered device video0 [v4l2]
> saa7133[0]: registered device vbi0
> ACPI: PCI Interrupt Link [ALKC] enabled at IRQ 22
> ACPI: PCI Interrupt :00:11.5[C] -> Link [ALKC] -> GSI 22 (level,
> low) -> IRQ 22
> PCI: Setting latency timer of device :00:11.5 to 64
> dvb_init() allocating 1 frontend
> nxt200x: NXT2004 Detected
> tuner-simple 1-0061: attaching existing instance
> tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual in)
> DVB: registering new adapter (saa7133[0])
> DVB: registering adapter 0 frontend 0 (Nextwave NXT200X VSB/QAM
> frontend)...
> nxt2004: Waiting for firmware upload (dvb-fe-nxt2004.fw)...
> nxt2004: Waiting for firmware upload(2)...
> nxt2004: Firmware upload complete

Would you like to see the results of after enabling 12c_scan to see what
is going on, or is this the behaviour you expected?


Some Other Miscellanea:
1) Before this gets merged, can I ask you to also make one small change
to tuner-simple; specifically, swap the contents of lines 301 and 304.  
This will change the driver's default behaviour in regards to the
selection of which RF input to use for digital cable and digital
over-the-air.  Currently, the driver is set to use digital OTA on the
top RF input and digital cable on the lower RF input spigot.  However,
IMO, a more logical/convenient configuration is to have the digital
cable input be handled by the top RF input spigot, as this is the same
one that the analog cable is also drawn from by default. Mike had made
this change, on my request, previously, but it appears that it got
reverted after the tuner re-factoring. 

Note:  users have reported different default configurations in the past
(e.g. http://www.mythtv.org/wiki/Kworld_ATSC_110), but I actually doubt
that there has been any manufacturing difference with the TUV1236D. 
Rather, I suspect that the user experiences being reported are just
reflecting a combination of the different states of how our driver
behaved in the past and differences in driver version that they may have
been using (i.e. that version provided by/within their distro or by our
Hg).  After all, this configuration setting has gone from being handled
by saa7134-dvb.c to dvb-pl

Re: KWorld ATSC 115 all static

[CityK]

CityK wrote:
> If you had meant taking Hans' source and applying your "hack" patch to
> them, building and then proceeding with the modprobe steps, the answer
> is that I haven't tried yet. Will test -- might not be tonight though,
> as I have some other things that need attending too.
>   

Okay, I lied -- given that building is really a background process, I
found time ... i.e. I cleaned up in the kitchen while the system
compiled ... kneel before me world, as I am a master multi-tasker!

>> Anyway, if the previous workaround works after Hans' changes, then I
>> think his changes should be merged -- even though it doesnt fix ATSC115,
>> it is indeed a step into the right direction.
>>
>> If the ATSC115 hack-fix patch doesn't apply anymore, please let me know
>> -- I'll respin it.
>> 

The "hack-fix" patch applies cleanly against Hans' sources. However, the
test results are negative -- the previous workaround ("modprobe tuner -r
and "modprobe tuner") fails to produce the desired result. In fact, as
similar to the results reported in the previous message, performing such
action produces no result in dmesg.
--
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 1/4] em28xx: Fix audio URB transfer buffer memory leak and race condition/corruption of capture pointer

[CityK]

Hi Robert,

I don't know if you're aware, but we've recently switched mailing lists
for which patches should be submitted (see Mauro's note:
http://www.linuxtv.org/news.php?entry=2009-01-06.mchehab) ... I've been
busy trying to update the likes of articles such as 
http://www.linuxtv.org/wiki/index.php/Development:_How_to_submit_patches 
that may have still contained instructions/links to the older mailing
lists.  Sorry for the inconvenience.  Unless Mauro, or a driver
maintainer has already picked them up, please resend them to the new list.
--
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] Siano 10226 Siano sub-system

[CityK]

Uri Shkolnik wrote:
> Where can I find checklist for that? (coding style and checkpatch.pl are for 
> the source code itself. Which document that covers this?)

In addition to the info Trent provided, if you haven't already found it,
there are a couple of documents in /usr/src/linux/Documentation that are
worthwhile skimming through. We have repeated them here in the wiki,
under the development section:
- http://www.linuxtv.org/wiki/index.php/Development:_Coding_Style
- http://www.linuxtv.org/wiki/index.php/Development:_Submitting_Patches
-
http://www.linuxtv.org/wiki/index.php/Development:_Linux_Kernel_patch_submittal_checklist
- http://www.linuxtv.org/wiki/index.php/Development:_Submitting_Drivers
As well as providing our own brief notice:
- http://www.linuxtv.org/wiki/index.php/Development:_How_to_submit_patches
--
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: [linux-dvb] Pinnacle dual Hybrid pro PCI-express - linuxTV!

[CityK]

Catimimi wrote:
> CityK a écrit :
>> Could you put it in the wiki if its not already contained there.  Thanks.
>>   
> It was done yesterday.

Yep, saw that about 10 minutes later after I responded to this message
:P .  Thanks.

--
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: KWorld ATSC 115 all static

[CityK]

Hans Verkuil wrote:

> is your board suppossed to have a tda9887 as well?

Hi Hans,

Yes, indeed, the device does contain the tda9887.


>> Hans' changes are not enough to fix the ATSC115 issue.
>> 
>
> Ah, OK.
>
>   
>> I believe that if you can confirm that the same problem exists, but the
>> previous workaround continues to work even after Hans' changes, then I
>> believe that confirms that Hans' changes Do the Right Thing (tm).
>> 

err, I'm afraid I might be reading to much into your statement Michael
--- if you meant to question whether, after building Hans' changes, a
"modprobe tuner -r" and "modprobe tuner " worked, then the answer is no,
such did not work. (no results in dmesg are observed either, much like
what was discussed later; specifically:

>  we are no longer able to remove the "tuner" module and modprobe it again --
> the second modprobe will not allow for an attach, as there will be no
> way for the module to be recognized 
>   

If you had meant taking Hans' source and applying your "hack" patch to
them, building and then proceeding with the modprobe steps, the answer
is that I haven't tried yet. Will test -- might not be tonight though,
as I have some other things that need attending too.

> Anyway, if the previous workaround works after Hans' changes, then I
> think his changes should be merged -- even though it doesnt fix ATSC115,
> it is indeed a step into the right direction.
>
> If the ATSC115 hack-fix patch doesn't apply anymore, please let me know
> -- I'll respin it.

Given this statement, then perhaps it was a case of the latter. As
mentioned, I will rebuild and test.

Hans, given the discussion that is developed, I don't think the dmesg
output is necessary at this point (if you really insist though I will
provide :P ).

P.S. I think Trent's idea sounds interesting/warrants some consideration.
--
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: eMPIA camera support?

[CityK]

hermann pitton wrote:
> Am Sonntag, den 28.12.2008, 21:54 -0500 schrieb CityK:
>   
>> hermann pitton wrote:
>>> schrieb CityK:
>>>> While the bttv gallery remains a very useful resource, I don't believe 
>>>> that Gunther is maintaining it any more. In any regard
>>>> let s use the V4L-DVB wiki 
>>>> (http://www.linuxtv.org/wiki/index.php/Main_Page), as it is best to keep 
>>>> the information all in one
>>>> place (i.e. a centralized repository of knowledge and information), as 
>>>> opposed to spread out across multiple 3rd party sources.  
>>> let's see. It still has lots of advantages.
>>> Hacking of hundreds of tuners and advanced gpio and eeprom detection was
>>> coordinated there on requests for research coming up on the lists and it
>>> has several thousand contributors. A wiki was not even in sight then.
>>>
>>> I would prefer to see it further maintained for easy searching on hard
>>> facts.
>>>
>>> At least don't call it third party.
>>>
>>> That is as mad as if you would call the video4linux-list or bytesex.org
>>> third party.
>>>
>>> It is/was to that point the official hardware resource and Gunther a
>>> leading tuner/hardware developer and nothing else.
>>>   
>> This is true, and I don't mean to offend anyone's sensibilities about
>> it.  Likewise, I did state that it remains a very useful resource.
>>
>> However, I haven't seen a word of boo from Gunther in probably two years
>> time.  Secondly, some of those users that I had, in the past, requested
>> that they submit material to the bttv-gallery have later written/replied
>> to me that their submissions went unanswered/unacknowledged.  Thirdly,
>> despite Gunther's distinguished history and involvement, it is likely
>> unclear to an unassuming end user that there is anything other then a
>> passing relation between the project and the "bttv-gallery".
>> 
>
> That is all OK so far.
>
> But it is not about sensibilities, but usability in the first place.
>   

Your points are duly noted ... and I have attempted to convey the crux
of your message in the note provided here: 
http://www.linuxtv.org/wiki/index.php/Development:_How_to_add_support_for_a_device#Don.27t_forget_to_send_info_to_the_Wiki_.21

> I give an example in short.
>
> http://linuxtv.org/wiki/index.php/DVB-T_PCI_Cards
>
> This starts with some ASUS My Cinema P7131-Dual model and the photos are
> taken from there. But that user had a P7131 Hybrid and he was the only
> one ever reporting problems like this,
>
> DVB, VDR, (***unstable*** causes random memory corruption and crashes),
>
> but stays on top of all recent PCI cards with hybrid tuners and speaks
> for all Asus saa713x ...
>
> This should be meanwhile eight different cards including the not yet
> externally documented Asus Tiger 3in1 I guess.
>
> It of cause continues here.
> http://linuxtv.org/wiki/index.php/ASUS_My_Cinema-P7131_Hybrid
>
> Almost all is wrong or at least not differentiated enough.
>
> If you look at the bttv-gallery for the related cards,
> there is at least _nothing_ wrong.
>   

Well, in these particular regards, I can only reply with what I have
previously noted in the wiki in several places, such as:
- from the Main page "welcome" message:   "Like all other wikis, the
V4L-DVB wiki relies upon the contributions of its users. Hence, it will
only be as useful as we make it!"
- from the DVB-T PCI Cards' note entitled "Please be aware that":  "The
information contained here is likely non-exhaustive and, despite best
efforts to do otherwise, may contain errors. (Please help to keep these
lists up-to-date so that they are useful for everyone!)"

--
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: KWorld ATSC 115 all static

[CityK]

Hans Verkuil wrote:
> OK, I couldn't help myself and went ahead and tested it. It seems fine, 
> so please test my tree: 
>
> http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-saa7134
>
> Let me know if it works. 

Hi Hans,

It didn't work.  No analog reception on either RF input.  (as Mauro
noted, DVB is unaffected; it still works).

dmesg output looks right:

tuner-simple 1-0061: creating new instance
tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual in)

I tried backing out of the modules and then reloading them, but no
change.  (including after fresh build or after rebooting)

--
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: [linux-dvb] Pinnacle dual Hybrid pro PCI-express - linuxTV!

[CityK]

Catimimi wrote:
> Hi,
>
> As I didn't yet subscribe to the list, I reply directly to your
> discussion with Romain

sorry, I don't recall it offhand.


> in ordezr to send you the result of :
>
> lspci -vvxxx
>
> for the Pinnacle PCTV Dual Hybrid Pro PCI Express (3010i)
>
> __
>
> 04:00.0 Multimedia controller: Philips Semiconductors Device 7162
> Subsystem: Pinnacle Systems Inc. Device 0100
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> SERR-  Latency: 0, Cache Line Size: 16 bytes
> Interrupt: pin A routed to IRQ 5
> Region 0: Memory at dde0 (64-bit, non-prefetchable) [size=1M]
> Capabilities: [40] Message Signalled Interrupts: Mask- 64bit+
> Queue=0/5 Enable-
> Address:   Data: 
> Capabilities: [50] Express (v1) Endpoint, MSI 00
> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s
> <256ns, L1 <1us
> ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
> DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> Unsupported-
> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
> MaxPayload 128 bytes, MaxReadReq 128 bytes
> DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr-
> TransPend-
> LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1,
> Latency L0 <4us, L1 <64us
> ClockPM- Suprise- LLActRep- BwNot-
> LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- Retrain-
> CommClk-
> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk-
> DLActive- BWMgmt- ABWMgmt-
> Capabilities: [74] Power Management version 2
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
> PME(D0+,D1+,D2+,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [80] Vendor Specific Information 
> 00: 31 11 62 71 07 00 10 00 00 00 80 04 04 00 00 00
> 10: 04 00 e0 dd 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 bd 11 00 01
> 30: 00 00 00 00 40 00 00 00 00 00 00 00 05 01 00 00
> 40: 05 50 8a 00 00 00 00 00 00 00 00 00 00 00 00 00
> 50: 10 74 01 00 80 00 28 00 10 00 0a 00 11 6c 03 01
> 60: 08 00 11 00 00 0a 00 00 00 00 00 00 00 00 00 00
> 70: 00 00 00 00 01 80 02 3e 00 00 00 00 00 00 00 00
> 80: 09 00 50 00 03 0c 00 00 02 02 00 00 00 00 00 00
> 90: 00 04 00 00 00 00 00 08 00 00 10 00 00 00 00 00
> a0: 01 00 00 04 03 18 00 00 00 00 01 04 00 00 00 00
> b0: 00 00 00 00 00 00 00 00 00 00 00 20 01 2a 00 00
> c0: 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> I hope it'll help.

Could you put it in the wiki if its not already contained there.  Thanks.

> I tried the driver found here : http://jusst.de/hg/saa716x
> It compiles and install, but if I try : modprobe saa716x_hybrid.ko
> I get a fatal error : module not found.
>
> I can't find any message in dmesg.

try without the ".ko", i.e. instead, use:

modprobe saa716x_hybrid

> Ready for further trials.
> Michel.


--
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: KWorld ATSC 115 all static

[CityK]

hermann pitton wrote:
> Hi,
>
> Am Montag, den 12.01.2009, 21:10 -0500 schrieb CityK:
>   
>> Hans Verkuil wrote:
>> 
>>> Yes, I can. I'll do saa7134 since I have an empress card anyway. It 
>>> should be quite easy (the cx18 complication is not an issue here).
>>>
>>> Regards,
>>>
>>> Hans
>>>   
>> Thanks Hans!
>>
>> 
>
> yes, Hans is a very fine guy.
>   

He is indeed.

> But don't hope for too much for DVB/ATSC related stuff soon.
>
> We know about the problems caused by switching antenna inputs from a
> digital demod, it was a famous hack from Chris on cx88xx and Mike did
> good work to port it to saa713x, but unfortunately there was some
> ongoing loss on the other side of the planet then later.
>
> I doubt that Hans is already aware of it at this stage, 

Consulting on irc, both Eric and myself can confirm that DVB is working
fine for the device (I can only test cable currently, but Eric
successfully checked both QAM and 8-VSB).  I'm using recent Hg and Eric
is using stock FC10 supplied drivers.  So, I'm not sure why Josh was
having problems.

> these days bugs are fixed from guys without even having hardware, 
Four letter word.  Starts with A and ends with Y  :p

> and this is good progress,
Yes, it was awfully nice of Andy to diagnose and provide a solution. 
Props to him.

>  likely they will add new devices the same way too soon.
>   

This point, however, is not a very good route to go down --- it opens up
a huge can of worms (<-- silly English expression which essentially
means that such action creates problems).
 
> I seem to be far behind currently, all caused by the HDTV hype ;)
>   

You mean you haven't upgraded to the latest 92 inch hyper plasma OXD
display yet!Crappy broadcast content has never looked so good!
--
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: [linux-dvb] OnAir creator seems to be recognized, but what device is what?

[CityK]

A. F. Cano wrote:
> Dvbusb2 seems to recognize the device ok.
> In fact it seems to create
>
> /dev/dvb/adapter0/demux0
> /dev/dvb/adapter0/dvr0
> /dev/dvb/adapter0/frontend0
> /dev/dvb/adapter0/net0
>
> And I also see /dev/video0
>
> But what do those devices represent?  Is /dev/video0 the analog tuner?
> is /dev/dvb/adapter0/dvr0 the digital tuner?  What are the others?
>   

When a driver module loads, the device manager udev will create device
nodes on /dev.

For dvb devices you get the character devices under /dev/dvb/adapterN
(where N = 0 to whatever). The character devices for each adapter N
are enumerated in form of M=0 to whatever. For example:
/dev/dvb/adapter0/frontend0  if the same device had a second
frontend, that character device would be enumerated by
/dev/dvb/adapter0/frontend1 ... if you had another dvb adapter in the
system, then you would see /dev/dvb/adapter1/frontend0 and so forth.

* The frontend device controls the tuner and demodulator.
* The demux controls the filters for processing the transport stream (TS).
* the dvr is a logical device that is associated with the demux
character device ... it delivers up the TS for either:
(1) immediate playback --- in which case it has to be decoded either:
a) on the device itself [its rare for PC devices to have hardware
decoding, but not so for STB] or
b) downstream by the system [the usual route for PC devices -- i.e.
software decoding via the host CPU, and possibly assisted by the GPU) ]
or
(2) saving to disk for later playback.
* the net character device controls IP-over-DVB

Similarly, with video capture (or, if you prefer, V4L) devices, you get
the /dev/video device node and the videoN character devices.

For more info, have a look at the DVB and V4L APIs.

> I have been trying to configure mythtv but have no idea what to tell it
> about this device.  The mythtv docs say that if you  have a card with 2
> tuners, define it as a DVB.  But, mythtv-setup identifies it correcly
> (by name) as an analog card /dev/video0, if I set it up as a DVB it claims
> it is a DVICO or Air2PC or...  It does not seem to know about the /dev/dvb
> devices.  Do I need to configure the OnAir Creator as 1 or 2 device 
>
> ... 
>
> I have posted the higher level questions to the mythtv mailing list, but
>
> no answers yet.  Any hints would be welcome.
>   

Sorry, no input on the myth specific questions, though surely someone
else might be able to.

> Can someone tell me a quick and easy way to test the device? maybe with
> mplayer?  I have an analog camera connected to the composite input, so
> even if I don't get any channels with the rabbit ears and loop antenna,
> that should work as a test.
See the wiki -- in particular, in the User Section, see the testing your
DVB device article. Also see the MPlayer article.


--
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: KWorld ATSC 115 all static

[CityK]

Hans Verkuil wrote:
> Yes, I can. I'll do saa7134 since I have an empress card anyway. It 
> should be quite easy (the cx18 complication is not an issue here).
>
> Regards,
>
>   Hans

Thanks 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

Re: KWorld ATSC 115 all static

[CityK]

Josh Borke wrote:
> After upgrading to Fedora 10 I am no longer able to tune analog or dvb
> channels using my KWorld ATSC 115. When I try to view a channel with
> tvtime all I can see is static and when I try to scandvb I keep
> getting tuning failed even though I know that there are channels being
> broadcast on the channels scanned. I have tried to find tips on the
> wiki of how to resolve my static problem but I could not find any. I'm
> not sure where to look for clues as to why it isn't working.
>
> I have a 1-to-4 splitter with 2 outputs going to the inputs of the
> KWorld ATSC and another going to a TV so I know there is signal on the
> cable.
>
> Any help would be really appreciated.

Josh,

The analog issue was obviously addressed in my last message.

Now, in regards to the DVB handling -- there have been a number of
recent Fedora 10 related problems being reported on the lists, and you
may happen to fall within that category.  I'd suggest having a look at
your dmesg output to see if there is any error being reported.  Saving
that -- search the lists in regard to the recent rash of Fedora
problems.  And finally, try switching the RF input on which you attempt
to obtain a digital signal. 

--
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: KWorld ATSC 115 all static

[CityK]

Josh Borke wrote:
> After upgrading to Fedora 10 I am no longer able to tune analog or dvb
> channels using my KWorld ATSC 115. When I try to view a channel with
> tvtime all I can see is static and when I try to scandvb I keep
> getting tuning failed even though I know that there are channels being
> broadcast on the channels scanned. I have tried to find tips on the
> wiki of how to resolve my static problem but I could not find any. I'm
> not sure where to look for clues as to why it isn't working.
>
> I have a 1-to-4 splitter with 2 outputs going to the inputs of the
> KWorld ATSC and another going to a TV so I know there is signal on the
> cable.
>
> Any help would be really appreciated.

Hello everyone,

In addition to being a general broadcast message, I have cc'ed  in a
number of folks.

This (broken analog TV on, at the very minimum, the KWorld 110 and 115
cards) is a known problem that has persisted for a long time.  Far too
long now.   I last wrote about it here: 
http://marc.info/?l=linux-video&m=122809741331944&w=2.  No response was
generated from that.  So I will try again and outline what I believe is
the relevant history:

- Mauro, you introduced a regression for these boards in changeset: 
7753:67faa17a5bcb  (http://linuxtv.org/hg/v4l-dvb/rev/67faa17a5bcb). 
Since that commit, analog TV has been broken for these cards.

- Michael commented about this here:
http://marc.info/?l=linux-video&m=121243712021921&w=2

- Mauro responded here: 
http://marc.info/?l=linux-video&m=121243995927725&w=2

- Several users have brought this up since then (both here on the m/l's
and on internet forums) .

- Michael spun a stopgap solution for this (found here
:http://linuxtv.org/~mkrufky/fix-broken-atsc110-analog.patch
 ).  It
still applies cleanly.  Unfortunately, it is not a bonafide solution
because: (a) upon each reboot of the system, the user is required to
first "modprobe tuner -r" and then "modprobe tuner" before the analog
tuning will initialize and function properly.  (b) In addition,
Michael's patch may affect/break other devices, so it can not be
committed to the master repo.

- Hans, I know you have done a lot of clean ups in regards to i2c, but
do not know whether any of your work would have touched upon or have had
any impact here.  Nonetheless, I'd appreciate your input on the matter
too if you are able to comment.

I am hoping that this can be resolved to everyone's satisfaction.  In my
opinion, this should become a priority item, as this regression's life
has spanned over 4 kernels.

[For the sake of full disclosure, I am personally affected by the issue,
but I note that I use Mike's patch each and everyday (thank you Mike!),
and so, other then the minor inconvenience of having to do a modprobe
dance with the tuner module, I am not impacted too much.  Other users,
however, are left in the dark.  And, as I explained in my last message,
those AVS users that I addressed this issue with seemed entirely
hesitant about using the patch (maybe I scared them with a greivious
warning ??).  Anyway, as evidenced by Josh  (OP for this message) and
David (see his recent messages; e.g.
http://marc.info/?l=linux-video&m=123066362106086&w=2), end users
continue to encounter  this problem.  I am only surprised that we
haven't heard more about this issue.  As I noted earlier on, I believe
that its impact is greater then just upon the KWorld 11x cards.]





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

[Fwd: Re: [linux-dvb] Post:/dev directory not populated while trying to use a Cinergy DT USB XS Diversity USB TV tuner]

[CityK]

Pierre-Jean BELIN wrote:

> Hello
>
> I am trying to use a TerraTec Cinergy DT USB XS Diversity USB key to
> broadcast video on my private network.
>
> I have followed tutorials from www.linuxtv.org but impossible to start
> the device.
>
> The key works correctly on Vista, so I am sure that the device is not
> out of order.
>
> My OS is a Fedora Sulfur ; kernel version : 2.6.27.9-73.fc9; my box is a 
> 64bits
>
> 1) I describe hereunder all the steps I followed to (unsuccessfully)
> start the key.
>
> Everything is based on www.linuxtv.org tutos.
>
> a) Installation of Mercurial and download of all the sources to
> compile the modules.
> b) As mentioned in the description of the key
> (http://www.linuxtv.org/wiki/index.php/TerraTec_Cinergy_DT_USB_XS_Diversity#Firmware)
> my device id is 0081 instead of 005a. Thus, I have modified (only
> replace 005a by 0081) the file
> linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h to take into account
> this change.
>
> Old line
> ==
>  #define USB_PID_TERRATEC_CINERGY_DT_XS_DIVERSITY0x005a
> ==
> New line
> ==
>  #define USB_PID_TERRATEC_CINERGY_DT_XS_DIVERSITY0x0081
> ==

Pierre,

It requires a little bit more more changes to the source code. See
Nicolas' patch, which he resubmitted (and hopefully gets picked up this
time) a few hours after your message:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg00138.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: dvb-t: searching for channels

[CityK]

Malte Gell wrote:
> dvbscan is from dvb-1.1.0_CVS20080331
>   

Err, that looks wrong. We haven't used CVS for quite some time (not sure
about the date, but pretty sure it was well before Mar 2008, so I'm
unclear about the copy you have).

In any regard, grab a fresh copy from here: http://www.linuxtv.org/repo/
(you can obtain it via either a tarball or using Mercurial). Build
instructions are also listed on that page (essentially make, make install).

Will this resolve your "Unable to query frontend status" problem? I
don't know, but this will be a good starting point. Failing that, lets
see the relevant output from dmesg.
--
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: dvb-t: searching for channels

[CityK]

Malte Gell wrote:
> Hello,
>
> I just purchased a Hauppauge Nova DVB-T USB stick and the kernel module and 
> firmware recognizes it well. I have first used Kaffeine to search for 
> channels, 
> but it has found none. 
>
> To be sure I even bought a better, an active dvb-t antenna with a 20dB 
> amplifier. And now I used dvbscan to scan for channels, I invoked it like 
> this:
>
> dvbscan -out channels /usr/share/dvb/dvb-t/de-Mannheim
>
> Is this the better way? It takes now longer than 15 minutes, is this normal? 
> Is dvbscan more reliable than kaffeine for searching for channels? If I still 
> find no channels, what could be the cause? In my region dvb-t signals are 
> said 
> to be not too well.
>   

For answers to some of your questions, see:
http://www.linuxtv.org/wiki/index.php/Scan
--
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