Help request
Hello; I have a DVICO dual express FusionHDTV7 card that I purchased about a year ago. In that year I have not been able to get both tuners recognized by linux. I only have a few minutes here and there to work on it and I have googled and followed every thread I can find, I have downloaded the v4l tree several times and compiled it, most of time it has compiled successfully and does in fact seem to enable one tuner. The newer firmware seems to load successfully. Mythtv successfully found the one tuner. I have read posts stating that they are using both tuners and would like some assistance in getting both of mine to work. I will happily provide whatever is requested to assist in diagnosis. Thank you very much in advance. Paul Kelly -- 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] radio-mr800: fix radio->muted and radio->stereo
Hello, Mauro This is simple fix for mr800 usb radio driver. It would be great to have it in next upstream pull request if you don't mind. --- Move radio->muted and radio->stereo in section where radio mutex is locked to avoid possible race condition problems or access to memory. Thanks to David Ellingsworth for pointing to this weak place in driver. Signed-off-by: Alexey Klimov -- diff -r 6a6eb9efc6cd linux/drivers/media/radio/radio-mr800.c --- a/linux/drivers/media/radio/radio-mr800.c Fri Jan 23 22:35:12 2009 -0200 +++ b/linux/drivers/media/radio/radio-mr800.c Sat Jan 24 07:22:38 2009 +0300 @@ -197,9 +197,9 @@ return retval; } + radio->muted = 0; + mutex_unlock(&radio->lock); - - radio->muted = 0; return retval; } @@ -233,9 +233,9 @@ return retval; } + radio->muted = 1; + mutex_unlock(&radio->lock); - - radio->muted = 1; return retval; } @@ -287,9 +287,9 @@ return retval; } + radio->stereo = 0; + mutex_unlock(&radio->lock); - - radio->stereo = 0; return retval; } -- Best regards, Klimov Alexey -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Need testers for s5h1409 tuning fix
On Fri, 2009-01-23 at 22:07 -0500, A. F. Cano wrote: > On Fri, Jan 23, 2009 at 08:31:18PM -0500, Andy Walls wrote: > > ... > > Since I was to lazy to get Kaffeine to work properly, I wrote my own > > test app. It is inline below so you can see how I measured the time. > > As I pointed out in another message recently I've been having problems > tuning my own pvrusb2 device (the OnAir Creator). I did encounter > problems in kaffeine, so I tried to compile your test app. A quick > perusal shows that it uses the /dvb/apapter0/* devices so it should > work here, but I can't compile it. I'm missing some *.h file: > > tuner.c: In function ‘main’: > tuner.c:51: error: array type has incomplete element type > tuner.c:52: error: storage size of ‘tasks’ isn’t known > tuner.c:68: error: ‘DTV_DELIVERY_SYSTEM’ undeclared (first use in this > function) > tuner.c:68: error: (Each undeclared identifier is reported only once > tuner.c:68: error: for each function it appears in.) > tuner.c:69: error: ‘SYS_ATSC’ undeclared (first use in this function) > tuner.c:71: error: ‘DTV_MODULATION’ undeclared (first use in this function) > tuner.c:76: error: ‘FE_SET_PROPERTY’ undeclared (first use in this function) > tuner.c:96: error: ‘DTV_FREQUENCY’ undeclared (first use in this function) > tuner.c:97: error: ‘DTV_TUNE’ undeclared (first use in this function) > > I'm running Debian Lenny. I did install the libdvb-dev package but that > wasn't it. There are libdvbpsi[345]-dev packages, but before I go > installing useless packages I thought I'd ask. The latest dvb/frontend.h header file that includes the DVB API v5 ioctl()s aren't include in most distributions yet. Here's how I compiled it, pointing to an include directory inside my development repository: $ gcc -Wall tune.c -o tune -I/home/andy/cx18dev/v4l-dvb/linux/include Be aware that my little app sets up ATSC 8-VSB modulation which is the driver default for my card anyway. Even if I left some settings out, I knew things would "just work". Also note that I have a hard coded frequency/channel table in the program useful for the terrestrial broadcasters near me, not necessarily near you. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Need testers for s5h1409 tuning fix
On Fri, 2009-01-23 at 21:50 -0500, Devin Heitmueller wrote: > On Fri, Jan 23, 2009 at 8:31 PM, Andy Walls wrote: > > For OTA ATSC 8-VSB with an HVR-1600 MCE: > > > > Without the change: > > > > $ ./tune > > Commanding tune to freq 479028615 ... FE_HAS_LOCK in 1.416984 seconds. > > Commanding tune to freq 551028615 ... FE_HAS_LOCK in 1.389922 seconds. > > Commanding tune to freq 569028615 ... FE_HAS_LOCK in 2.783927 seconds. > > Commanding tune to freq 587028615 ... FE_HAS_LOCK in 1.391952 seconds. > > Commanding tune to freq 593028615 ... NO lock after 2.999655 seconds. > > Commanding tune to freq 599028615 ... FE_HAS_LOCK in 1.568240 seconds. > > Commanding tune to freq 605028615 ... FE_HAS_LOCK in 1.390964 seconds. > > Commanding tune to freq 623028615 ... NO lock after 2.999656 seconds. > > Commanding tune to freq 677028615 ... FE_HAS_LOCK in 2.963289 seconds. > > Commanding tune to freq 695028615 ... NO lock after 2.999618 seconds. > > > > With the change: > > > > $ ./tune > > Commanding tune to freq 479028615 ... FE_HAS_LOCK in 1.323542 seconds. > > Commanding tune to freq 551028615 ... FE_HAS_LOCK in 1.293956 seconds. > > Commanding tune to freq 569028615 ... FE_HAS_LOCK in 1.292931 seconds. > > Commanding tune to freq 587028615 ... FE_HAS_LOCK in 1.292973 seconds. > > Commanding tune to freq 593028615 ... FE_HAS_LOCK in 1.292920 seconds. > > Commanding tune to freq 599028615 ... FE_HAS_LOCK in 1.293977 seconds. > > Commanding tune to freq 605028615 ... FE_HAS_LOCK in 1.292940 seconds. > > Commanding tune to freq 623028615 ... FE_HAS_LOCK in 1.292949 seconds. > > Commanding tune to freq 677028615 ... FE_HAS_LOCK in 1.293948 seconds. > > Commanding tune to freq 695028615 ... NO lock after 2.999659 seconds. > > > > > > No lock was expected for 695 MHz in either case - it was known negative. > > > > Since I was to lazy to get Kaffeine to work properly, I wrote my own > > test app. It is inline below so you can see how I measured the time. > > > > Regards, > > Andy > > Hello Andy, > > This is great. Your data confirms with that device that you're now > getting a lock 100% of the time in a consistent time period. Yup. Strangely enough, the measurments for both cases yield very repeatable results. The "bad" numbers always come out in about the same relative times. I suppose that might change, if I changed the order of which frequencies were tuned. > I > actually got my hands on my own HVR-1600 tonight, and with the > mxl5005s datasheet I got from Maxlinear last week, I will be looking > at lock performance in general for that tuner. I think you might need to pry the can open for that one. Looking at the linux driver code, I get the feeling that external components can be set up differently for various tracking filter configurations. Of course, Steve Toth added the Hauppauge variant tracking filter settings for the HVR-1600. > Thanks again for doing this testing. No problem. Let me know if there's something else you need tested. Now that I've bothered to write a DVB API v5 test app, I've actually started to read the DVB API v3 document and the API v5 code. I understand some of the linux DVB internal architecture concepts now. (My day job has also had me reading the ETSI DVB-S2 standards documentation this past week anyway.) > Mkrufky has indicated he wants > to do some testing this weekend, and assuming that happens I will > submit a PULL request first thing next week. > > Devin Regards, Andy -- 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: How can I fix errors and warnings in nvidia module for Tesla C1060
On Sat, Jan 24, 2009 at 8:33 AM, Ionut Leonte wrote:
> According to the log you attached ("Kernel messages" section):
>
> nvidia: module license 'NVIDIA' taints kernel.
> NVRM: No NVIDIA graphics adapter found!
>
> Are you sure you're using the correct driver ?
>
Nvidia Tesla C1060 has no output, so I was using intel motherboard
garphics, when I disable intel motherboard graphics adapter
installation processes able to find nvidia graphics adapter and build
the nvidia module.
But now I got another problem I use various git kernels trees, so I
need to build these modules for each kernel tree. And seems nvidia is
not disclosing the source code for Nvidia Telsa Series module :-(
--
JSR
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Need testers for s5h1409 tuning fix
On Fri, Jan 23, 2009 at 08:31:18PM -0500, Andy Walls wrote: > ... > Since I was to lazy to get Kaffeine to work properly, I wrote my own > test app. It is inline below so you can see how I measured the time. As I pointed out in another message recently I've been having problems tuning my own pvrusb2 device (the OnAir Creator). I did encounter problems in kaffeine, so I tried to compile your test app. A quick perusal shows that it uses the /dvb/apapter0/* devices so it should work here, but I can't compile it. I'm missing some *.h file: tuner.c: In function ‘main’: tuner.c:51: error: array type has incomplete element type tuner.c:52: error: storage size of ‘tasks’ isn’t known tuner.c:68: error: ‘DTV_DELIVERY_SYSTEM’ undeclared (first use in this function) tuner.c:68: error: (Each undeclared identifier is reported only once tuner.c:68: error: for each function it appears in.) tuner.c:69: error: ‘SYS_ATSC’ undeclared (first use in this function) tuner.c:71: error: ‘DTV_MODULATION’ undeclared (first use in this function) tuner.c:76: error: ‘FE_SET_PROPERTY’ undeclared (first use in this function) tuner.c:96: error: ‘DTV_FREQUENCY’ undeclared (first use in this function) tuner.c:97: error: ‘DTV_TUNE’ undeclared (first use in this function) I'm running Debian Lenny. I did install the libdvb-dev package but that wasn't it. There are libdvbpsi[345]-dev packages, but before I go installing useless packages I thought I'd ask. A. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Need testers for s5h1409 tuning fix
On Fri, Jan 23, 2009 at 8:31 PM, Andy Walls wrote: > For OTA ATSC 8-VSB with an HVR-1600 MCE: > > Without the change: > > $ ./tune > Commanding tune to freq 479028615 ... FE_HAS_LOCK in 1.416984 seconds. > Commanding tune to freq 551028615 ... FE_HAS_LOCK in 1.389922 seconds. > Commanding tune to freq 569028615 ... FE_HAS_LOCK in 2.783927 seconds. > Commanding tune to freq 587028615 ... FE_HAS_LOCK in 1.391952 seconds. > Commanding tune to freq 593028615 ... NO lock after 2.999655 seconds. > Commanding tune to freq 599028615 ... FE_HAS_LOCK in 1.568240 seconds. > Commanding tune to freq 605028615 ... FE_HAS_LOCK in 1.390964 seconds. > Commanding tune to freq 623028615 ... NO lock after 2.999656 seconds. > Commanding tune to freq 677028615 ... FE_HAS_LOCK in 2.963289 seconds. > Commanding tune to freq 695028615 ... NO lock after 2.999618 seconds. > > With the change: > > $ ./tune > Commanding tune to freq 479028615 ... FE_HAS_LOCK in 1.323542 seconds. > Commanding tune to freq 551028615 ... FE_HAS_LOCK in 1.293956 seconds. > Commanding tune to freq 569028615 ... FE_HAS_LOCK in 1.292931 seconds. > Commanding tune to freq 587028615 ... FE_HAS_LOCK in 1.292973 seconds. > Commanding tune to freq 593028615 ... FE_HAS_LOCK in 1.292920 seconds. > Commanding tune to freq 599028615 ... FE_HAS_LOCK in 1.293977 seconds. > Commanding tune to freq 605028615 ... FE_HAS_LOCK in 1.292940 seconds. > Commanding tune to freq 623028615 ... FE_HAS_LOCK in 1.292949 seconds. > Commanding tune to freq 677028615 ... FE_HAS_LOCK in 1.293948 seconds. > Commanding tune to freq 695028615 ... NO lock after 2.999659 seconds. > > > No lock was expected for 695 MHz in either case - it was known negative. > > Since I was to lazy to get Kaffeine to work properly, I wrote my own > test app. It is inline below so you can see how I measured the time. > > Regards, > Andy Hello Andy, This is great. Your data confirms with that device that you're now getting a lock 100% of the time in a consistent time period. I actually got my hands on my own HVR-1600 tonight, and with the mxl5005s datasheet I got from Maxlinear last week, I will be looking at lock performance in general for that tuner. Thanks again for doing this testing. Mkrufky has indicated he wants to do some testing this weekend, and assuming that happens I will submit a PULL request first thing next week. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Need testers for s5h1409 tuning fix
On Fri, 2009-01-23 at 14:36 -0500, Devin Heitmueller wrote:
>
> It would be good if you could provide some actual data regarding
> before and after the patch. Typically I run Kaffeine from the command
> line, which prints out the tuning time to stdout. For example, here
> are the times Robert saw when he tested my patch:
>
> Before the change:
> Tuning delay: 2661 ms
> Tuning delay: 474 ms
> Tuning delay: 472 ms
> Tuning lock fail after 5000ms
> Tuning delay: 2000 ms
> Tuning delay: 2685 ms
> Tuning delay: 475 ms
>
> After the change:
> Tuning delay: 594 ms
> Tuning delay: 570 ms
> Tuning delay: 574 ms
> Tuning delay: 671 ms
> Tuning delay: 570 ms
> Tuning delay: 673 ms
>
> If you could provide something comparable, it would be useful.
For OTA ATSC 8-VSB with an HVR-1600 MCE:
Without the change:
$ ./tune
Commanding tune to freq 479028615 ... FE_HAS_LOCK in 1.416984 seconds.
Commanding tune to freq 551028615 ... FE_HAS_LOCK in 1.389922 seconds.
Commanding tune to freq 569028615 ... FE_HAS_LOCK in 2.783927 seconds.
Commanding tune to freq 587028615 ... FE_HAS_LOCK in 1.391952 seconds.
Commanding tune to freq 593028615 ... NO lock after 2.999655 seconds.
Commanding tune to freq 599028615 ... FE_HAS_LOCK in 1.568240 seconds.
Commanding tune to freq 605028615 ... FE_HAS_LOCK in 1.390964 seconds.
Commanding tune to freq 623028615 ... NO lock after 2.999656 seconds.
Commanding tune to freq 677028615 ... FE_HAS_LOCK in 2.963289 seconds.
Commanding tune to freq 695028615 ... NO lock after 2.999618 seconds.
With the change:
$ ./tune
Commanding tune to freq 479028615 ... FE_HAS_LOCK in 1.323542 seconds.
Commanding tune to freq 551028615 ... FE_HAS_LOCK in 1.293956 seconds.
Commanding tune to freq 569028615 ... FE_HAS_LOCK in 1.292931 seconds.
Commanding tune to freq 587028615 ... FE_HAS_LOCK in 1.292973 seconds.
Commanding tune to freq 593028615 ... FE_HAS_LOCK in 1.292920 seconds.
Commanding tune to freq 599028615 ... FE_HAS_LOCK in 1.293977 seconds.
Commanding tune to freq 605028615 ... FE_HAS_LOCK in 1.292940 seconds.
Commanding tune to freq 623028615 ... FE_HAS_LOCK in 1.292949 seconds.
Commanding tune to freq 677028615 ... FE_HAS_LOCK in 1.293948 seconds.
Commanding tune to freq 695028615 ... NO lock after 2.999659 seconds.
No lock was expected for 695 MHz in either case - it was known negative.
Since I was to lazy to get Kaffeine to work properly, I wrote my own
test app. It is inline below so you can see how I measured the time.
Regards,
Andy
/*
* tune.c - Measure the time to tune some hardcoded ATSC OTA channels
* Copyright (C) 2009 Andy Walls
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
* Author: Andy Walls
*
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
unsigned int test_freq[] = {
479028615,
551028615,
569028615,
587028615,
593028615,
599028615,
605028615,
623028615,
677028615,
695028615,
0
};
int main(int argc, char *argv[])
{
int fd, ret, i;
struct dtv_property task[3];
struct dtv_properties tasks;
struct timeval tv, stv, etv;
int n, watch;
fd_set efds;
struct dvb_frontend_event fev;
fd = open("/dev/dvb/adapter0/frontend0", O_RDWR|O_NONBLOCK);
if (fd < 0) {
perror("open");
exit(1);
}
tasks.props = task;
/* Basic ATSC 8-VSB setup */
task[0].cmd = DTV_DELIVERY_SYSTEM;
task[0].u.data = SYS_ATSC;
task[0].result = 0;
task[1].cmd = DTV_MODULATION;
task[1].u.data = VSB_8;
task[1].result = 0;
tasks.num = 2;
ret = ioctl(fd, FE_SET_PROPERTY, &tasks);
if (ret < 0) {
perror("FE_SET_PROPERTY");
close(fd);
exit(2);
}
ret = 0;
for(i = 0; i < tasks.num; i++) {
if (task[i].result < 0)
ret = task[i].result;
}
if (ret < 0) {
fprintf(stderr, "Failed to set ATSC 8-VSB modulation.\n");
close(fd);
exit(3);
}
/* Tune test loop */
task[0].cmd = DTV_FREQUENCY;
task[1].cmd = D
i.MX31 Camera Sensor Interface support
Hi all, I uploaded my current patch-stack for the i.MX31 Camera Sensor Interface to http://gross-embedded.homelinux.org/~lyakh/i.MX31-20090124/ (to be submitted later, hopefully for 2.6.30). As stated in -base-unknown, these patches shall be used on top of the git://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx.git tree "upstream" branch. Please also notice that the server will be offline for the most of the day tomorrow (CET), after which it should come back to the usual 24x7 visibility (although under different IPs:-)). Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression since 2.6.25 kernel: Crash of userspace program leaves DVB device unusable
Andy Walls wrote (Tuesday 20 January 2009): > On Mon, 2009-01-19 at 19:43 +1000, Brendon Higgins wrote: > > Summary procedure, starting with a working dvb: > > 1) rmmod cx88_dvb > > 2) modprobe cx88_dvb > > Error: No such device. > > 3) rmmod cx8802 > > 4) modprobe cx88_dvb > > Success (and cx8802 is pulled in automatically) > > > > So it seems there might be some sort of module interdependency not being > > taken care of. > > Yes. Mauro did some work to decouple these modules in very recent > changes. I did some follow-up changes to fix frontend allocations. You > may want to try the latest v4l-dvb repository. Just did that, grabbed v4l-dvb-2ed72b192848, and it seems to be fixed there. No complaints when rmmoding and modprobing the modules. There's something about it that xine and mplayer don't seem to like (though I can't be sure they worked previously - FWIW, xine won't change channels and when you try it causes "dvb_demux_feed_del: feed not in list (type=0 state=0 pid=)" in syslog, mplayer... well I haven't figured out the interface, anyway), but vdr seems just fine with it, which is my primary concern. It would be my luck that by the time I figure out what's actually going on I can't help because it's already fixed. :-) Peace, Brendon signature.asc Description: This is a digitally signed message part.
Re: [linux-dvb] Upcoming DVB-T channel changes for HH (Hamburg)
Mojn, as people say in the north and to the north of northern germany ;-) On Fri, 23 Jan 2009, Tobias Stöber wrote: > Well, just have to send this message again, this time to the right & > correct mailing list linux-...@linuxtv.org. (Who by the way had the > insane idea, to set a reply-to address to another mailing list It also means that the original sender may not ever see a reply, unless one overrides this and uses the From: header, which I'm now doing in most replies, because except for a handful of developers, I really have no idea if the original poster of a message to -dvb is even subscribed to any other list. Most of the time, I'll guess they aren't. Meaning the reply stays on -dvb assuming I reply to all. As a result, pretty much everybody is crossposting between -dvb and -media rather than the so-called ``wanted'' effect of abandoning -dvb and keeping all posts in one location, that is, -media. Naturally, posts that are delivered directly to me do not contain this header, so my replies don't make it to that other list. Frankly, I ain't bothered anymore. > As for certain area in Saxony-Anhalt, Saxony and Thuringia there ahve Argh! Don't do this ;-) You're making me run for my englisch-to-german dictionary which contains none of these. But anyway... > in my area (Brunswick), where there had been an ARD Mux on Ch 8. Now it Okay, this isn't in my dictionary either, and while I could guess the others, I have no clue. Sounds Canadian to me, which says more about my background, than of non-native place names which I avoid (Milano it is; I grew up not far from Milan and I am not good-looking and sexy and sophisticated like the italians) But that is neither here nor there... > Information for the whole NDR area will normally be found at > http://www.dvb-t-nord.de. So far, only old info from last year is what I've found there. Likewise, the site for Bayern did not give me any info about plans to migrate the number of VHF frequencies into the UHF band, while it did have a few interesting bits of information not provided by the technically excellent, up-to-date, and informative BayernText teletext pages. > There is a complete listing including parameters from "in area" and also > "out of area" (but with reception in the area) transmitters at > http://www.ueberallfernsehen.de/data/senderliste_25_11_2008.pdf Interesting, thanks. This gives me the overview by region that I lack apart from Baden-Württemberg, Bayern, and the like, as to the modulation in use -- mdr and to some extent WDR do not follow the same pattern as seen in B-W I believe there is a mistake, though, in the data for HH. The guard interval of 1/8 for all frequencies, both VHF and UHF, from one Turm (font too small) does not match the 1/4 used as a general rule throughout germany, and used by all the (UHF) frequencies in the Single-Frequency-Network formed by the other Standort. (The modulation parameters provided in the initial scan file for Lübeck seem to be wrong too -- the one which caught my eye when quickly viewing all de-scanfiles) Even though my original plans to create a comprehensive list of frequencies, transmitter sites, and technical details for each Bundesland have been put on ice, as I don't expect to be doing any travel to these areas in the near future, it will be interesting for me to come up with an overview of available quality in each region, as well as to puzzle over what WDR is doing. I wonder if, in addition to moving from the remaining VHF frequencies, there will be plans in the future to convert to a unified horizontal or vertical polarisation nationally or by region. Though this does not affect tuning data, it is apparently an issue around Nürnberg... barry bouwsma -- 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] cx24116 & roll-off factor = auto
Le vendredi 23 janvier 2009 22:44:35 Goga777, vous avez écrit : > > For example, DVB-S uses only rolloff = 0.35, so if the driver knows that > > the chip can't accept auto value, it should use 0.35 value by default in > > that case. > > good idea. Anybody against ? That's already the case with cx24116, 0.35 is used for dvb-s -- Christophe Thommeret -- 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: [GIT PULL -tip] fix 33 make headers_check warnings
Jan Engelhardt wrote:
Hm, maybe g++ defaults to std? Because this works without me using
"using std;"
#include
int main(void)
{
uint32_t x;
}
Sorry, this was a bit of a surprise... basically the g++
functionally does #include then exports the symbols into the
std namespace, so it puts them into both...
-hpa
--
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: [GIT PULL -tip] fix 33 make headers_check warnings
On Friday 2009-01-23 22:33, H. Peter Anvin wrote:
>>
>> I had an objection as previously stated -- namely that
>> should be included to remain friendly to C++0x
>> programs which should use instead. Forcing
>> stdint.h is therefore not nice.
>
> FWIW, it's kind of pointless in that case; exports it into the std::
> namespace rather than the root namespace, so using stdint types still don't
> work.
Hm, maybe g++ defaults to std? Because this works without me using
"using std;"
#include
int main(void)
{
uint32_t x;
}
--
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: [GIT PULL -tip] fix 33 make headers_check warnings
Jan Engelhardt wrote: I had an objection as previously stated -- namely that should be included to remain friendly to C++0x programs which should use instead. Forcing stdint.h is therefore not nice. FWIW, it's kind of pointless in that case; exports it into the std:: namespace rather than the root namespace, so using stdint types still don't work. It again comes down to: for headers exported to userspace we *have* to use double-underscore types. -hpa -- 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
[PULL] http://linuxtv.org/hg/~tmerle/v4l-dvb
Forwarding to the right list... Message original Sujet: [PULL] http://linuxtv.org/hg/~tmerle/v4l-dvb Date: Fri, 23 Jan 2009 19:12:31 +0100 De: Thierry Merle Pour :: Mauro Carvalho Chehab , v4l-dvb maintainer list Hi Mauro, Please pull from: http://linuxtv.org/hg/~tmerle/v4l-dvb for the following changes: - usbvision: use usb_make_path to report bus info - em28xx: use usb_make_path to report bus info - gspca: use usb_make_path to report bus info - uvcvideo: use usb_make_path to report bus info - s2255drv: use usb_make_path to report bus info em28xx/em28xx-video.c |4 ++-- gspca/gspca.c |3 +-- s2255drv.c |3 +-- usbvision/usbvision-video.c |3 +-- uvc/uvc_v4l2.c |8 5 files changed, 9 insertions(+), 12 deletions(-) These are the usb_make_path() modification on all remaining usb drivers. Laurent Pinchart acked the patch on uvcvideo. For the others, since this is the same manipulation the code is safe to make these modifications. Cheers, Thierry -- 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] cx24116 & roll-off factor = auto
> For example, DVB-S uses only rolloff = 0.35, so if the driver knows that the > chip can't accept auto value, it should use 0.35 value by default in that > case. good idea. Anybody against ? Goga -- 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 remote RM-KS for Avermedia Volar-X (af9015)
Jose Alberto Reguero wrote: Signed-off-by: Felipe Morales Moreno This SOB is broken, can I get correct one. Antti -- http://palosaari.fi/ -- 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] Upcoming DVB-T channel changes for HH (Hamburg)
Moin, moin (as people say in Northern Germany) :) BOUWSMA Barry schrieb: I've just learned that effective 24.Feb, there will be a change made to the channel assignment in the area of Hamburg. This is due to the fact that one existing multiplex is found within the VHF band, which is in the process of being cleared of DVB-T services, moving them to assigned UHF channels, in order to free the VHF band for radio services (DAB/DAB+ and family). Several other areas, such as Bayern, currently make use of VHF frequencies at several transmitter sites. I am not yet aware of what plans exist to change these frequencies... As for certain area in Saxony-Anhalt, Saxony and Thuringia there ahve never been VHF channels in use. Tis applies normally only to area from the first stage of the German DVB-T project. Lower Saxony has recently (November 2008) cleared several channels, like in my area (Brunswick), where there had been an ARD Mux on Ch 8. Now it is on Ch 47. The following diff will add the newly assigned frequency, and remove the old one, with an effective date of 24.Feb. The particular modulation parameters are not confirmed, so I've had to guess based on existing values used elsewhere in the NDR coverage area as well as what generally is used throughout germany. Information for the whole NDR area will normally be found at http://www.dvb-t-nord.de. There is a complete listing including parameters from "in area" and also "out of area" (but with reception in the area) transmitters at http://www.ueberallfernsehen.de/data/senderliste_25_11_2008.pdf So have a look ;) Best regards, Tobias -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Need testers for s5h1409 tuning fix
On Fri, 2009-01-23 at 14:36 -0500, Devin Heitmueller wrote: > On Fri, Jan 23, 2009 at 1:05 PM, Andy Walls wrote: > > Holy cow! the thing tunes fast now! > > > > One burst error I received seemed much more devasting to mplayer's > > decoder than it usually does though. (I guess fast tuning or relocking > > may have it's disadvantages, but decoding errant streams as sanely as > > possible is more a software decoder's problem.) > > > > Propagation conditions here today are much better than in recent days > > due to weather changes (it's close to 50 F!). I'll test tonight around > > sunset and later when things get colder, to get more more data points > > for what happens when burts errors occur. > > > > But right now, it looks very good. :D > > > > Regards, > > Andy > > Glad to hear that it is working well for you. > > Could you please clarify what you mean by "burst error"? A momentary deep channel fade. I'm located > 75 miles from the TV broadcasters. Lots of opportunity for weather effects or aircraft to come between my location and the broadcast towers. In fact, rotary wing aircraft fly by to the north of my location within eye-sight and earshot during the day somewhat regularly during the week. They always momentarily disrupt reception as they pass by. Before mplayer would log one maybe two lines of errors during such an event. With the change in place, mplayer now logs > 24 lines worth of errors. I assume, that's because with the change in place the 8-VSB demodulator is now reacting faster to the poor channel condition. For eaxmple, Here's what mplayer will blurt out during a burst error with the change in place: a52: CRC check failed! a52: error at resampling [mpeg2video @ 0xab61c0]invalid mb type in I Frame at 23 22 0% 0.9% 1 0 28% [mpeg2video @ 0xab61c0]skipped MB in I frame at 14 25 [mpeg2video @ 0xab61c0]invalid mb type in I Frame at 1 28 [mpeg2video @ 0xab61c0]ac-tex damaged at 1 29 [mpeg2video @ 0xab61c0]concealing 333 DC, 333 AC, 333 MV errors [mpeg2video @ 0xab61c0]skipped MB in I frame at 7 2634 6% 0% 0.9% 1 0 28% [mpeg2video @ 0xab61c0]skipped MB in I frame at 4 6 [mpeg2video @ 0xab61c0]skipped MB in I frame at 19 10 [mpeg2video @ 0xab61c0]skipped MB in I frame at 41 24 [mpeg2video @ 0xab61c0]concealing 220 DC, 220 AC, 220 MV errors [mpeg2video @ 0xab61c0]ac-tex damaged at 6 19635/14635 6% 0% 0.9% 1 0 28% [mpeg2video @ 0xab61c0]concealing 176 DC, 176 AC, 176 MV errors [mpeg2video @ 0xab61c0]00 motion_type at 25 5637/14637 6% 0% 0.9% 1 0 28% [mpeg2video @ 0xab61c0]concealing 135 DC, 135 AC, 135 MV errors [mpeg2video @ 0xab61c0]invalid mb type in B Frame at 42 27 0% 0.9% 1 0 28% [mpeg2video @ 0xab61c0]concealing 44 DC, 44 AC, 44 MV errors [mpeg2video @ 0xab61c0]ac-tex damaged at 37 2639/14639 6% 0% 0.9% 1 0 28% [mpeg2video @ 0xab61c0]00 motion_type at 3 28 [mpeg2video @ 0xab61c0]ac-tex damaged at 0 29 [mpeg2video @ 0xab61c0]concealing 176 DC, 176 AC, 176 MV errors [mpeg2video @ 0xab61c0]00 motion_type at 22 2740/14640 6% 0% 0.9% 1 0 28% [mpeg2video @ 0xab61c0]mb incr damaged [mpeg2video @ 0xab61c0]00 motion_type at 1 27 [mpeg2video @ 0xab61c0]00 motion_type at 4 28 [mpeg2video @ 0xab61c0]ac-tex damaged at 6 29 [mpeg2video @ 0xab61c0]concealing 132 DC, 132 AC, 132 MV errors [mpeg2video @ 0xab61c0]00 motion_type at 34 2641/14641 6% 0% 0.9% 1 0 28% [mpeg2video @ 0xab61c0]concealing 176 DC, 176 AC, 176 MV errors [mpeg2video @ 0xab61c0]slice mismatch0.406 14643/14643 6% 0% 0.9% 1 0 29% [mpeg2video @ 0xab61c0]concealing 968 DC, 968 AC, 968 MV errors [mpeg2video @ 0xab61c0]invalid mb type in I Frame at 28 6% 0% 0.9% 1 0 29% [mpeg2video @ 0xab61c0]ac-tex damaged at 24 9 [mpeg2video @ 0xab61c0]invalid mb type in I Frame at 1 27 [mpeg2video @ 0xab61c0]skipped MB in I frame at 1 28 [mpeg2video @ 0xab61c0]invalid mb type in I Frame at 1 29 [mpeg2video @ 0xab61c0]concealing 1276 DC, 1276 AC, 1276 MV errors [mpeg2video @ 0xab61c0]skipped MB in I frame at 15 196 6% 0% 0.9% 1 0 28% [mpeg2video @ 0xab61c0]skipped MB in I frame at 36 22 [mpeg2video @ 0xab61c0]ac-tex damaged at 13 26 [mpeg2video @ 0xab61c0]concealing 352 DC, 352 AC, 352 MV errors Before, I'd only get a few (2 to 6) lines upon such an event. > For my record keeping, could you please confirm which hardware you are > doing the testing with? This is important since there could be an > issue with your demod/tuner combination. HVR-1600 MCE. It has an MXL5005s with a CX24227 (S5H1409). Look in linux/drivers/media/video/cx18/cx18-dvb.c to see how it's being set up. > It would be good if you could provide some actual data regarding > before and after the patch.Typically I run Kaffeine from the command > line, which prints out the tuning time to stdout. For example, here > are the times Robert saw when he tested my patch: > > Before the change: > Tuning delay: 2661 ms > Tuning delay: 474 ms > Tuning delay: 472 ms > Tuning lock fail after 5000ms >
Re: New remote RM-KS for Avermedia Volar-X (af9015)
Jose Alberto Reguero wrote: The new Avermedia Volar-X is shipped with a new remote(RM-KS). The attached patch add a new option to the remote parameter of dvb_usb_af9015 for this remote. Signed-off-by: Felipe Morales Moreno Signed-off-by: Jose Alberto Reguero Patch looked correctly and I PULL-requested it. Anyhow, may I ask how Avermedia handles this new remote. Does they ship two drivers, one for new remote and one for old remote? regards Antti -- http://palosaari.fi/ -- 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] cx24116 & roll-off factor = auto
Le vendredi 23 janvier 2009 20:49:24 Goga777, vous avez écrit : > > > does support cx24116 the roll-off factor = auto ? > > > > no > > who should be care about of corrected roll-off factor which have to send to > cx24116 - the drivers or user software ? does roll-off factor = 0,35 good > for 99% dvb-s2 channels ? The scanning app should get the rolloff factor. Yes, 0.35 is most likely. -- Christophe Thommeret -- 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] Which firmware for cx23885 and xc3028?
On Fri, 2009-01-23 at 19:41 +0100, lno...@dragon.unideb.hu wrote:
> Wayne and Holly wrote:
>
> >> I am trying to make an AverMedia AverTV Hybrid Express (A577)
> >> work under Linux. It seems all major chips (cx23885, xc3028
> >> and af9013) are already supported, so it should be doable in
> >> principle.
> >>
> >> I am stuck a little bit since AFAIK both cx23885 and xc3028
> >> need an uploadable firmware. Where should I download/extract
> >> such firmware from? I tried Steven Toth's repo (the Hauppauge
> >> HVR-1400 seems to be built around these chips as well) but
> >> even after copying the files under /lib/firmware it didn't
> >> really work. I tried to specify different cardtypes for the
> >> cx23885 module. For cardtype=2 I got a /dev/video0 and a
> >> /dev/video1 (the latter is of course unusable, I don't have a
> >> MPEG encoder chip on my card) but tuning was unsuccesful. All
> >> the other types I tried either didn't work at all or only
> >> resulted in dvb devices detected. For the moment, I am fine
> >> without DVB, and are interested mainly in analog devices.
> >>
> >> Maybe I should locate the windows driver of my card and
> >> extract the firmware files from it? If so, how do I proceed?
> >>
> >
> > Have you followed these instructions?:
> > http://www.linuxtv.org/wiki/index.php/Xceive_XC3028/XC2028#How_to_Obtain_the
> > _Firmware
> >
>
> Tried xc3028-v27.fw as well as v36 from Steven's site. There is nothing
> showing up in the syslog when modprobing tuner-xc2028 (the doc mentions
> the kernel driver should indicate which part it loads).
>
> What's the situation with cx23885? After digging into the various docs
> and descriptions pertaining to this chip, it's still not clear whether I
> need a firmware (and if so, where from may I download/extract it).
The publicly available product brief for that chip is here:
http://www.conexant.com/products/entry.jsp?id=393
Given that the Linux driver tries to
request_module("cx25840");
for some CX23885 boards and that the cx25840 linux module has cx23885
specific code in it, it's safe to assume you'll need the
"v4l-cx23885-avcore-01.fw" file from somewhere. It's function is likely
very similar to firmware for the cx25840, but it's also very likely the
images are subtly different and hence not interchangable.
Since you don't have a CX23417 MPEG encoder chip handing off the bridge,
you shouldn't need the "v4l-cx23885-fw.enc" file.
I know very little about this driver myself, so I can't speak to the
state of analog support for any supported card, much less how well an
unsupported card may work.
Regards,
Andy
> Many thanks for your help!
>
> Greetings,
>
> Levente
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Need testers for s5h1409 tuning fix
On Fri, Jan 23, 2009 at 1:05 PM, Andy Walls wrote: > Holy cow! the thing tunes fast now! > > One burst error I received seemed much more devasting to mplayer's > decoder than it usually does though. (I guess fast tuning or relocking > may have it's disadvantages, but decoding errant streams as sanely as > possible is more a software decoder's problem.) > > Propagation conditions here today are much better than in recent days > due to weather changes (it's close to 50 F!). I'll test tonight around > sunset and later when things get colder, to get more more data points > for what happens when burts errors occur. > > But right now, it looks very good. :D > > Regards, > Andy Glad to hear that it is working well for you. Could you please clarify what you mean by "burst error"? For my record keeping, could you please confirm which hardware you are doing the testing with? This is important since there could be an issue with your demod/tuner combination. It would be good if you could provide some actual data regarding before and after the patch. Typically I run Kaffeine from the command line, which prints out the tuning time to stdout. For example, here are the times Robert saw when he tested my patch: Before the change: Tuning delay: 2661 ms Tuning delay: 474 ms Tuning delay: 472 ms Tuning lock fail after 5000ms Tuning delay: 2000 ms Tuning delay: 2685 ms Tuning delay: 475 ms After the change: Tuning delay: 594 ms Tuning delay: 570 ms Tuning delay: 574 ms Tuning delay: 671 ms Tuning delay: 570 ms Tuning delay: 673 ms If you could provide something comparable, it would be useful. Thank you for taking the time to test. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Need testers for s5h1409 tuning fix
On Fri, Jan 23, 2009 at 12:48 PM, Andy Walls wrote: > I will test soon, but I do have two comments by inspection. > > 1. The function s5h1409_softreset() is now called 3 times by > s5h1409_set_frontend(): once at entry, once by > s5h1409_enable_modulation(), and once at exit. Surely at least one of > these is not needed, no? > > 2. You've eliminated the 100 ms "settle delay" after the final > softreset. Can something from userland turn around and call one of the > s5h1409_ops vectors and muck with registers before things "settle"? > Does it even matter? > > I know a hardware reset requires a long-ish assertion time (in fact now > that I see it, I have to fix the cx18 driver hardware reset assertion > delay for this device - the current value isn't right). > > Regards, > Andy Just to be clear, the term "softreset" is somewhat a misnomer. It is *not* a software equivalent of a hardware reset. It does not reset any of the configuration registers. It only resets the internal status data that is used to determine lock status. The 100ms settle delay should not be needed at all. If there is a concern about something in userland mucking with the registers, that is something that would have to be addressed through locking. As far as I know, there is no known issue associated with querying the status registers as soon as the status counters are reset. It is possible that the softreset() before the tune may not be necessary, but at this point my intent was to focus on the minimal change that achieves the desired effect, and the additional softreset() should not cause any performance or reliability impact. Also, the change I made is consistent with the change I made for the s5h1411 back in October (for which there have been no problems reported). Yes, traditionally a hardware reset needs to be asserted for a specific period of time (varies by device). That does not apply here though since the chip itself is not being reset. There is additional room for optimization, but this fix alone provides a significant performance benefit and is low impact, so I wanted to get it merged independent of any other fixes. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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/~anttip/af9015/
Hello Mauro, I updated this PULL request with one new patch adding support for new remote. Please pull from http://linuxtv.org/hg/~anttip/af9015/ for the following: af9015: remove dual_mode module param af9015: New remote RM-KS for Avermedia Volar-X Patch removes af9015 dual_mode module param. Possible 2nd FE seems not to be buggy any more and therefore can be enabled as default. regards Antti -- http://palosaari.fi/ -- 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
[cron job] WARNINGS: armv5 armv5-ixp armv5-omap2 i686 m32r mips powerpc64 x86_64 v4l-dvb build
(This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below.) Results of the daily build of v4l-dvb: date:Fri Jan 23 19:00:08 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 10303:2ed72b192848 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.16.61-armv5: OK linux-2.6.17.14-armv5: OK linux-2.6.18.8-armv5: OK linux-2.6.19.5-armv5: OK linux-2.6.20.21-armv5: OK linux-2.6.21.7-armv5: OK linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: WARNINGS linux-2.6.28-armv5: WARNINGS linux-2.6.29-rc2-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29-rc2-armv5-ixp: OK linux-2.6.27-armv5-omap2: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29-rc2-armv5-omap2: OK linux-2.6.16.61-i686: OK linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: OK linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29-rc2-i686: OK linux-2.6.16.61-m32r: OK linux-2.6.17.14-m32r: OK linux-2.6.18.8-m32r: OK linux-2.6.19.5-m32r: OK linux-2.6.20.21-m32r: OK linux-2.6.21.7-m32r: OK linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29-rc2-m32r: OK linux-2.6.16.61-mips: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-rc2-mips: OK linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29-rc2-powerpc64: OK linux-2.6.16.61-x86_64: OK linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: OK linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29-rc2-x86_64: OK fw/apps: OK sparse (linux-2.6.28): ERRORS sparse (linux-2.6.29-rc2): ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 -- 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] cx24116 & roll-off factor = auto
Le vendredi 23 janvier 2009 18:58:54 Goga777, vous avez écrit : > Hi > > does support cx24116 the roll-off factor = auto ? no -- Christophe Thommeret -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Need testers for s5h1409 tuning fix
On Wed, 2009-01-21 at 23:45 -0500, Devin Heitmueller wrote: > The attached patch significantly improves tuning lock times for all > three s5h1409 based devices I have tested with so far. However, > because of the large number of devices affected, I would like to > solicit people with products that use the s5h1409 to test the patch > and report back any problems before it gets committed. > > To test the patch, check out the latest v4l-dvb and apply the patch: > > hg clone http://linuxtv.org/hg/v4l-dvb > cd v4l-dvb > patch -p1 < s5h1409_tuning_speedup.patch > make > make install > make unload > reboot > > Based on the data collected thus far, this patch should address some > long-standing issues with long times to reach tuning lock and > intermittent lock failures. > > Comments welcome. Holy cow! the thing tunes fast now! One burst error I received seemed much more devasting to mplayer's decoder than it usually does though. (I guess fast tuning or relocking may have it's disadvantages, but decoding errant streams as sanely as possible is more a software decoder's problem.) Propagation conditions here today are much better than in recent days due to weather changes (it's close to 50 F!). I'll test tonight around sunset and later when things get colder, to get more more data points for what happens when burts errors occur. But right now, it looks very good. :D Regards, Andy > Thanks, > > Devin -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Need testers for s5h1409 tuning fix
On Wed, 2009-01-21 at 23:45 -0500, Devin Heitmueller wrote: > The attached patch significantly improves tuning lock times for all > three s5h1409 based devices I have tested with so far. However, > because of the large number of devices affected, I would like to > solicit people with products that use the s5h1409 to test the patch > and report back any problems before it gets committed. > > To test the patch, check out the latest v4l-dvb and apply the patch: > > hg clone http://linuxtv.org/hg/v4l-dvb > cd v4l-dvb > patch -p1 < s5h1409_tuning_speedup.patch > make > make install > make unload > reboot > > Based on the data collected thus far, this patch should address some > long-standing issues with long times to reach tuning lock and > intermittent lock failures. > > Comments welcome. I will test soon, but I do have two comments by inspection. 1. The function s5h1409_softreset() is now called 3 times by s5h1409_set_frontend(): once at entry, once by s5h1409_enable_modulation(), and once at exit. Surely at least one of these is not needed, no? 2. You've eliminated the 100 ms "settle delay" after the final softreset. Can something from userland turn around and call one of the s5h1409_ops vectors and muck with registers before things "settle"? Does it even matter? I know a hardware reset requires a long-ish assertion time (in fact now that I see it, I have to fix the cx18 driver hardware reset assertion delay for this device - the current value isn't right). Regards, Andy > Thanks, > > Devin > -- 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
New remote RM-KS for Avermedia Volar-X (af9015)
The new Avermedia Volar-X is shipped with a new remote(RM-KS). The attached
patch add a new option to the remote parameter of dvb_usb_af9015 for this
remote.
Signed-off-by: Felipe Morales Moreno
Signed-off-by: Jose Alberto Reguero
Jose Alberto
diff -r 2ed72b192848 linux/drivers/media/dvb/dvb-usb/af9015.c
--- a/linux/drivers/media/dvb/dvb-usb/af9015.c Thu Jan 22 22:20:24 2009 -0600
+++ b/linux/drivers/media/dvb/dvb-usb/af9015.c Fri Jan 23 16:51:52 2009 +0100
@@ -751,6 +751,16 @@
af9015_config.ir_table_size =
ARRAY_SIZE(af9015_ir_table_digittrade);
break;
+ case AF9015_REMOTE_AVERMEDIA_KS:
+af9015_properties[i].rc_key_map =
+ af9015_rc_keys_avermedia;
+af9015_properties[i].rc_key_map_size =
+ ARRAY_SIZE(af9015_rc_keys_avermedia);
+af9015_config.ir_table =
+ af9015_ir_table_avermedia_ks;
+af9015_config.ir_table_size =
+ ARRAY_SIZE(af9015_ir_table_avermedia_ks);
+break;
}
} else {
switch (le16_to_cpu(udev->descriptor.idVendor)) {
diff -r 2ed72b192848 linux/drivers/media/dvb/dvb-usb/af9015.h
--- a/linux/drivers/media/dvb/dvb-usb/af9015.h Thu Jan 22 22:20:24 2009 -0600
+++ b/linux/drivers/media/dvb/dvb-usb/af9015.h Fri Jan 23 16:51:52 2009 +0100
@@ -124,6 +124,7 @@
AF9015_REMOTE_MSI_DIGIVOX_MINI_II_V3,
AF9015_REMOTE_MYGICTV_U718,
AF9015_REMOTE_DIGITTRADE_DVB_T,
+ AF9015_REMOTE_AVERMEDIA_KS,
};
/* Leadtek WinFast DTV Dongle Gold */
@@ -597,6 +598,36 @@
0x03, 0xfc, 0x03, 0xfc, 0x0e, 0x05, 0x00,
};
+static u8 af9015_ir_table_avermedia_ks[] = {
+ 0x05, 0xfa, 0x01, 0xfe, 0x12, 0x05, 0x00,
+ 0x05, 0xfa, 0x02, 0xfd, 0x0e, 0x05, 0x00,
+ 0x05, 0xfa, 0x03, 0xfc, 0x0d, 0x05, 0x00,
+ 0x05, 0xfa, 0x04, 0xfb, 0x2e, 0x05, 0x00,
+ 0x05, 0xfa, 0x05, 0xfa, 0x2d, 0x05, 0x00,
+ 0x05, 0xfa, 0x06, 0xf9, 0x10, 0x05, 0x00,
+ 0x05, 0xfa, 0x07, 0xf8, 0x0f, 0x05, 0x00,
+ 0x05, 0xfa, 0x08, 0xf7, 0x3d, 0x05, 0x00,
+ 0x05, 0xfa, 0x09, 0xf6, 0x1e, 0x05, 0x00,
+ 0x05, 0xfa, 0x0a, 0xf5, 0x1f, 0x05, 0x00,
+ 0x05, 0xfa, 0x0b, 0xf4, 0x20, 0x05, 0x00,
+ 0x05, 0xfa, 0x0c, 0xf3, 0x21, 0x05, 0x00,
+ 0x05, 0xfa, 0x0d, 0xf2, 0x22, 0x05, 0x00,
+ 0x05, 0xfa, 0x0e, 0xf1, 0x23, 0x05, 0x00,
+ 0x05, 0xfa, 0x0f, 0xf0, 0x24, 0x05, 0x00,
+ 0x05, 0xfa, 0x10, 0xef, 0x25, 0x05, 0x00,
+ 0x05, 0xfa, 0x11, 0xee, 0x26, 0x05, 0x00,
+ 0x05, 0xfa, 0x12, 0xed, 0x27, 0x05, 0x00,
+ 0x05, 0xfa, 0x13, 0xec, 0x04, 0x05, 0x00,
+ 0x05, 0xfa, 0x15, 0xea, 0x0a, 0x05, 0x00,
+ 0x05, 0xfa, 0x16, 0xe9, 0x11, 0x05, 0x00,
+ 0x05, 0xfa, 0x17, 0xe8, 0x15, 0x05, 0x00,
+ 0x05, 0xfa, 0x18, 0xe7, 0x16, 0x05, 0x00,
+ 0x05, 0xfa, 0x1c, 0xe3, 0x05, 0x05, 0x00,
+ 0x05, 0xfa, 0x1d, 0xe2, 0x09, 0x05, 0x00,
+ 0x05, 0xfa, 0x4d, 0xb2, 0x3f, 0x05, 0x00,
+ 0x05, 0xfa, 0x56, 0xa9, 0x3e, 0x05, 0x00
+};
+
/* Digittrade DVB-T USB Stick */
static struct dvb_usb_rc_key af9015_rc_keys_digittrade[] = {
{ 0x01, 0x0f, KEY_LAST }, /* RETURN */
Re: [GIT PULL -tip] fix 33 make headers_check warnings
On Fri, 2009-01-23 at 18:09 +0100, Sam Ravnborg wrote: > On Fri, Jan 23, 2009 at 10:01:44PM +0530, Jaswinder Singh Rajput wrote: > > So is this OK: > > > > -#ifdef __KERNEL__ > > #include > > -#else > > -#include > > -#endif > > That was what I expected the final change to look like. > If you want then combine it in one patch. > Ok, thanks. -- JSR -- 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: TinyTwin (af9015) Results and questions
Lindsay Mathieson wrote: to enable the second tuner. I thought that would be on by default now the 2nd tuner bugs have been worked out. Done. - Is there a official place to download the firmware from? Currently I'm getting it from: http://www.otit.fi/~crope/v4l-dvb/af9015/af9015_firmware_cutter/firmware_files/4.95.0/dvb-usb-af9015.fw That's "official". I think it is not wanted to linuxtv.org because there is same as almost every firmware - it does not have any license. It is just extracted out from Windows driver (actually from USB-sniff). I think some distributions will package & deliver this kind of firmwares, though. - Is it possible to estimate when this will make its way into the linux kernel? How will I know? Driver is in 2.6.28, with dual mode disabled & broken. I am not sure whether those fixes are coming to 2.6.29 or 2.6.30, I doubt later Kernel. I ask because I'd like to write up a howto for myth and/or ubuntu users, and want to cover all bases. regards Antti -- http://palosaari.fi/ -- 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: [GIT PULL -tip] fix 33 make headers_check warnings
On Fri, Jan 23, 2009 at 10:01:44PM +0530, Jaswinder Singh Rajput wrote: > On Fri, 2009-01-23 at 17:21 +0100, Sam Ravnborg wrote: > > On Fri, Jan 23, 2009 at 05:11:13PM +0100, Jan Engelhardt wrote: > > > > > > On Friday 2009-01-23 17:04, Jaswinder Singh Rajput wrote: > > > >> > diff --git a/include/linux/dvb/audio.h b/include/linux/dvb/audio.h > > > >> > index 89412e1..758a48c 100644 > > > >> > --- a/include/linux/dvb/audio.h > > > >> > +++ b/include/linux/dvb/audio.h > > > >> > @@ -24,9 +24,8 @@ > > > >> > #ifndef _DVBAUDIO_H_ > > > >> > #define _DVBAUDIO_H_ > > > >> > > > > >> > -#ifdef __KERNEL__ > > > >> > #include > > > >> > -#else > > > >> > +#ifndef __KERNEL__ > > > >> > #include > > > >> > #endif > > > >> > > > > >> > > > >> It seems one have objection for this. So I will again insert this in my > > > >> new patchset. > > > >> > > > > > > > >oops, s/seems one/seems no one ;-) > > > > > > I had an objection as previously stated -- namely that > > > should be included to remain friendly to C++0x > > > programs which should use instead. Forcing > > > stdint.h is therefore not nice. > > > > This is fully agreed. > > Jaswinder - can I ask you to do this change (remove of the stdint.h include) > > in a follow-up patch. It is two independent changes. > > You original patch is fine as is. > > So is this OK: > > -#ifdef __KERNEL__ > #include > -#else > -#include > -#endif That was what I expected the final change to look like. If you want then combine it in one patch. Sam -- 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: [hg:v4l-dvb] Merge from master v4l-dvb repo
On Fri, 23 Jan 2009 11:59:09 -0500 Andy Walls wrote: > On Thu, 2009-01-22 at 23:05 +0100, Patch added by Andy Walls wrote: > > The patch number 10282 was added via Andy Walls > > to http://linuxtv.org/hg/v4l-dvb master development tree. > > > > Kernel patches in this development tree may be modified to be backward > > compatible with older kernels. Compatibility modifications will be > > removed before inclusion into the mainstream Kernel > > > > If anyone has any objections, please let us know by sending a message to: > > Linux Media Mailing List > > No objection per se, just a concern: > > This was a "make pull" I unwittingly did on my ~awalls/v4l-dvb repo that > I mentioned. Hopefully hg is smart enough not to have this merge back > to the main v4l-dvb repo and cause unintentional reverts. > Mercurial will add your merges on its story. The only drawback is to have mercurial history more dirty. > -- > > Merge from master v4l-dvb repo > > Instead, please use: merge: Since my scripts get the string "merge:" on the subject to discard the patches when porting to -git tree. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [linux-dvb] Which firmware for cx23885 and xc3028?
> -Original Message- > From: linux-dvb-boun...@linuxtv.org > [mailto:linux-dvb-boun...@linuxtv.org] On Behalf Of Levente Novák > Sent: Friday, 23 January 2009 1:57 p.m. > To: linux-...@linuxtv.org > Subject: [linux-dvb] Which firmware for cx23885 and xc3028? > > > I am trying to make an AverMedia AverTV Hybrid Express (A577) > work under Linux. It seems all major chips (cx23885, xc3028 > and af9013) are already supported, so it should be doable in > principle. > > I am stuck a little bit since AFAIK both cx23885 and xc3028 > need an uploadable firmware. Where should I download/extract > such firmware from? I tried Steven Toth's repo (the Hauppauge > HVR-1400 seems to be built around these chips as well) but > even after copying the files under /lib/firmware it didn't > really work. I tried to specify different cardtypes for the > cx23885 module. For cardtype=2 I got a /dev/video0 and a > /dev/video1 (the latter is of course unusable, I don't have a > MPEG encoder chip on my card) but tuning was unsuccesful. All > the other types I tried either didn't work at all or only > resulted in dvb devices detected. For the moment, I am fine > without DVB, and are interested mainly in analog devices. > > Maybe I should locate the windows driver of my card and > extract the firmware files from it? If so, how do I proceed? > > Thanks in advance! > > Levente > > Have you followed these instructions?: http://www.linuxtv.org/wiki/index.php/Xceive_XC3028/XC2028#How_to_Obtain_the _Firmware Cheers Wayne -- 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: [hg:v4l-dvb] Merge from master v4l-dvb repo
On Thu, 2009-01-22 at 23:05 +0100, Patch added by Andy Walls wrote: > The patch number 10282 was added via Andy Walls > to http://linuxtv.org/hg/v4l-dvb master development tree. > > Kernel patches in this development tree may be modified to be backward > compatible with older kernels. Compatibility modifications will be > removed before inclusion into the mainstream Kernel > > If anyone has any objections, please let us know by sending a message to: > Linux Media Mailing List No objection per se, just a concern: This was a "make pull" I unwittingly did on my ~awalls/v4l-dvb repo that I mentioned. Hopefully hg is smart enough not to have this merge back to the main v4l-dvb repo and cause unintentional reverts. Rgards, Andy > -- > > Merge from master v4l-dvb repo > > > --- > > README.patches | 38 > linux/Documentation/video4linux/v4lgrab.c| 25 > linux/arch/arm/mach-pxa/devices.c| 112 + > linux/arch/arm/mach-pxa/pcm990-baseboard.c | 10 > linux/drivers/media/common/tuners/tda8290.c |6 > linux/drivers/media/common/tuners/tuner-simple.c |9 > linux/drivers/media/dvb/dm1105/Kconfig |1 > linux/drivers/media/dvb/dvb-core/dvb_frontend.c | 26 > linux/drivers/media/dvb/dvb-core/dvbdev.c|8 > linux/drivers/media/dvb/dvb-usb/anysee.c |2 > linux/drivers/media/dvb/dvb-usb/dib0700_devices.c| 18 > linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h|2 > linux/drivers/media/dvb/frontends/cx24116.c |2 > linux/drivers/media/dvb/frontends/lgdt3304.c | 10 > linux/drivers/media/dvb/frontends/s921_module.c |2 > linux/drivers/media/dvb/frontends/stb0899_algo.c |7 > linux/drivers/media/dvb/frontends/stb0899_drv.c |6 > linux/drivers/media/dvb/siano/sms-cards.c| 23 > linux/drivers/media/dvb/ttpci/budget-ci.c|4 > linux/drivers/media/video/bt8xx/bttv-driver.c|1 > linux/drivers/media/video/cafe_ccic.c|1 > linux/drivers/media/video/cs5345.c |1 > linux/drivers/media/video/cx23885/cx23885-417.c |3 > linux/drivers/media/video/cx23885/cx23885-video.c|5 > linux/drivers/media/video/cx25840/cx25840-core.c |2 > linux/drivers/media/video/cx88/Kconfig |5 > linux/drivers/media/video/cx88/Makefile |3 > linux/drivers/media/video/cx88/cx88-dvb.c| 90 + > linux/drivers/media/video/cx88/cx88-i2c.c| 28 > linux/drivers/media/video/cx88/cx88-mpeg.c | 30 > linux/drivers/media/video/cx88/cx88.h|6 > linux/drivers/media/video/em28xx/em28xx-cards.c |5 > linux/drivers/media/video/em28xx/em28xx-core.c | 11 > linux/drivers/media/video/em28xx/em28xx-input.c |2 > linux/drivers/media/video/em28xx/em28xx-video.c | 59 > linux/drivers/media/video/em28xx/em28xx.h| 21 > linux/drivers/media/video/gspca/m5602/m5602_s5k83a.c |2 > linux/drivers/media/video/ivtv/ivtv-driver.c |4 > linux/drivers/media/video/ov7670.c |1 > linux/drivers/media/video/ovcamchip/ovcamchip_core.c |1 > linux/drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h | 12 > linux/drivers/media/video/pvrusb2/pvrusb2-hdw.c | 25 > linux/drivers/media/video/pvrusb2/pvrusb2-hdw.h |6 > linux/drivers/media/video/pvrusb2/pvrusb2-sysfs.c| 12 > linux/drivers/media/video/pvrusb2/pvrusb2-v4l2.c |2 > linux/drivers/media/video/pwc/pwc-if.c |1 > linux/drivers/media/video/pxa_camera.c |6 > linux/drivers/media/video/pxa_camera.h | 95 + > linux/drivers/media/video/saa7127.c | 68 > linux/drivers/media/video/saa7134/saa7134-core.c |4 > linux/drivers/media/video/saa717x.c |1 > linux/drivers/media/video/tveeprom.c |3 > linux/drivers/media/video/tvp514x.c |2 > linux/drivers/media/video/upd64031a.c|1 > linux/drivers/media/video/upd64083.c |1 > linux/drivers/media/video/usbvideo/ibmcam.c |2 > linux/drivers/media/video/usbvideo/konicawc.c|2 > linux/drivers/media/video/usbvideo/ultracam.c|2 > linux/drivers/media/video/usbvision/usbvision-video.c|3 > linux/drivers/media/video/uvc/uvc_ctrl.c |7 > linux/drivers/media/video/uvc/uvc_driver.c | 55 > linux/drivers/media/video/uvc/uvc_isi
Re: [GIT PULL -tip] fix 33 make headers_check warnings
On Fri, 2009-01-23 at 17:21 +0100, Sam Ravnborg wrote: > On Fri, Jan 23, 2009 at 05:11:13PM +0100, Jan Engelhardt wrote: > > > > On Friday 2009-01-23 17:04, Jaswinder Singh Rajput wrote: > > >> > diff --git a/include/linux/dvb/audio.h b/include/linux/dvb/audio.h > > >> > index 89412e1..758a48c 100644 > > >> > --- a/include/linux/dvb/audio.h > > >> > +++ b/include/linux/dvb/audio.h > > >> > @@ -24,9 +24,8 @@ > > >> > #ifndef _DVBAUDIO_H_ > > >> > #define _DVBAUDIO_H_ > > >> > > > >> > -#ifdef __KERNEL__ > > >> > #include > > >> > -#else > > >> > +#ifndef __KERNEL__ > > >> > #include > > >> > #endif > > >> > > > >> > > >> It seems one have objection for this. So I will again insert this in my > > >> new patchset. > > >> > > > > > >oops, s/seems one/seems no one ;-) > > > > I had an objection as previously stated -- namely that > > should be included to remain friendly to C++0x > > programs which should use instead. Forcing > > stdint.h is therefore not nice. > > This is fully agreed. > Jaswinder - can I ask you to do this change (remove of the stdint.h include) > in a follow-up patch. It is two independent changes. > You original patch is fine as is. So is this OK: -#ifdef __KERNEL__ #include -#else -#include -#endif - -- JSR -- 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: [GIT PULL -tip] fix 33 make headers_check warnings
On Fri, Jan 23, 2009 at 05:11:13PM +0100, Jan Engelhardt wrote: > > On Friday 2009-01-23 17:04, Jaswinder Singh Rajput wrote: > >> > diff --git a/include/linux/dvb/audio.h b/include/linux/dvb/audio.h > >> > index 89412e1..758a48c 100644 > >> > --- a/include/linux/dvb/audio.h > >> > +++ b/include/linux/dvb/audio.h > >> > @@ -24,9 +24,8 @@ > >> > #ifndef _DVBAUDIO_H_ > >> > #define _DVBAUDIO_H_ > >> > > >> > -#ifdef __KERNEL__ > >> > #include > >> > -#else > >> > +#ifndef __KERNEL__ > >> > #include > >> > #endif > >> > > >> > >> It seems one have objection for this. So I will again insert this in my > >> new patchset. > >> > > > >oops, s/seems one/seems no one ;-) > > I had an objection as previously stated -- namely that > should be included to remain friendly to C++0x > programs which should use instead. Forcing > stdint.h is therefore not nice. This is fully agreed. Jaswinder - can I ask you to do this change (remove of the stdint.h include) in a follow-up patch. It is two independent changes. You original patch is fine as is. Thanks, Sam -- 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: [GIT PULL -tip] fix 33 make headers_check warnings
On Friday 2009-01-23 17:04, Jaswinder Singh Rajput wrote: >> > diff --git a/include/linux/dvb/audio.h b/include/linux/dvb/audio.h >> > index 89412e1..758a48c 100644 >> > --- a/include/linux/dvb/audio.h >> > +++ b/include/linux/dvb/audio.h >> > @@ -24,9 +24,8 @@ >> > #ifndef _DVBAUDIO_H_ >> > #define _DVBAUDIO_H_ >> > >> > -#ifdef __KERNEL__ >> > #include >> > -#else >> > +#ifndef __KERNEL__ >> > #include >> > #endif >> > >> >> It seems one have objection for this. So I will again insert this in my >> new patchset. >> > >oops, s/seems one/seems no one ;-) I had an objection as previously stated -- namely that should be included to remain friendly to C++0x programs which should use instead. Forcing stdint.h is therefore not nice. -- 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
[PULL] http://linuxtv.org/hg/~anttip/af9015/
Hello Mauro, Please pull from http://linuxtv.org/hg/~anttip/af9015/ for the following: af9015: remove dual_mode module param Patch removes af9015 dual_mode module param. Possible 2nd FE seems not to be buggy any more and therefore can be enabled as default. regards Antti -- http://palosaari.fi/ -- 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: [GIT PULL -tip] fix 33 make headers_check warnings
On Fri, 2009-01-23 at 21:29 +0530, Jaswinder Singh Rajput wrote:
> On Wed, 2009-01-21 at 06:08 +0530, Jaswinder Singh Rajput wrote:
> > On Sat, 2009-01-17 at 14:26 -0800, H. Peter Anvin wrote:
> > > Sam Ravnborg wrote:
> > > >>>
> > > >> That patch looks wrong, and unnecessary. It was fine before.
> > > > Nope - include/linux/dvb/audio.h failed to include linux/types.h
> > > > despite the fact that is uses __u32 etc.
> > > >
> > > > But why the _kernel_ should include a userspace header is
> > > > much more questionable.
> > > >
> > >
> > > is one of a handful of headers provided by gcc itself.
> > >
> >
> > Should I reintroduce my patch to solve this warning of 'make headers_check':
> > usr/include/linux/dvb/audio.h:133: found __[us]{8,16,32,64} type without
> > #include
> >
> > diff --git a/include/linux/dvb/audio.h b/include/linux/dvb/audio.h
> > index 89412e1..758a48c 100644
> > --- a/include/linux/dvb/audio.h
> > +++ b/include/linux/dvb/audio.h
> > @@ -24,9 +24,8 @@
> > #ifndef _DVBAUDIO_H_
> > #define _DVBAUDIO_H_
> >
> > -#ifdef __KERNEL__
> > #include
> > -#else
> > +#ifndef __KERNEL__
> > #include
> > #endif
> >
>
> It seems one have objection for this. So I will again insert this in my
> new patchset.
>
oops, s/seems one/seems no one ;-)
--
JSR
--
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: [GIT PULL -tip] fix 33 make headers_check warnings
On Wed, 2009-01-21 at 06:08 +0530, Jaswinder Singh Rajput wrote:
> On Sat, 2009-01-17 at 14:26 -0800, H. Peter Anvin wrote:
> > Sam Ravnborg wrote:
> > >>>
> > >> That patch looks wrong, and unnecessary. It was fine before.
> > > Nope - include/linux/dvb/audio.h failed to include linux/types.h
> > > despite the fact that is uses __u32 etc.
> > >
> > > But why the _kernel_ should include a userspace header is
> > > much more questionable.
> > >
> >
> > is one of a handful of headers provided by gcc itself.
> >
>
> Should I reintroduce my patch to solve this warning of 'make headers_check':
> usr/include/linux/dvb/audio.h:133: found __[us]{8,16,32,64} type without
> #include
>
> diff --git a/include/linux/dvb/audio.h b/include/linux/dvb/audio.h
> index 89412e1..758a48c 100644
> --- a/include/linux/dvb/audio.h
> +++ b/include/linux/dvb/audio.h
> @@ -24,9 +24,8 @@
> #ifndef _DVBAUDIO_H_
> #define _DVBAUDIO_H_
>
> -#ifdef __KERNEL__
> #include
> -#else
> +#ifndef __KERNEL__
> #include
> #endif
>
It seems one have objection for this. So I will again insert this in my
new patchset.
--
JSR
--
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: [GIT PULL -tip] fix 33 make headers_check warnings
On Sat, 2009-01-17 at 23:18 -0500, Kyle McMartin wrote: > On Sun, Jan 18, 2009 at 09:08:24AM +0530, Jaswinder Singh Rajput wrote: > > If this file is _ONLY_ for userspace and kernel cannot use it then what > > is the point of keeping this file in kernel headers. > > > > There is effectively no point, especially when they reference a variable > that may or may not exist in the userspace code including it... It seems > entirely mtd-utils dependent. > > Dave, will you queue Adrian's patch to nuke it? What is the status of include/mtd/jffs2-user.h -- JSR -- 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
Martin Edlman napsal(a): >>> I have a problem with module cx23885, it doesn't create the /dev/video0 >>> device. >>> >> The module doesn't support analogue yet. > > Hmmm, that's not a good new. Is there a plan to add analogue support? When? Is there a possibility someone will take care of analogue support on WinFast PxDVR 3200 H? If yes, I can test it, send debug outputs, be a beta tester, just say. I can even help with development, I have a litle bit experience with kernel module programming. So if someone gives me a clue I can do little modifications myself (changing some values to see which one is the right one, ... maybe more). Regards, 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
Re: [linux-dvb] Which firmware for cx23885 and xc3028?
Try to extract the firmware using this Script: /Documentation/video4linux/extract_xc3028.pl A howto is included the header of the script. Best regards Stephan Wienczny Am Freitag 23 Januar 2009 13:56:40 schrieb Levente Novák: > I am trying to make an AverMedia AverTV Hybrid Express (A577) work under > Linux. It seems all major chips (cx23885, xc3028 and af9013) are already > supported, so it should be doable in principle. > > I am stuck a little bit since AFAIK both cx23885 and xc3028 need an > uploadable firmware. Where should I download/extract such firmware from? > I tried Steven Toth's repo (the Hauppauge HVR-1400 seems to be built > around these chips as well) but even after copying the files > under /lib/firmware it didn't really work. I tried to specify different > cardtypes for the cx23885 module. For cardtype=2 I got a /dev/video0 and > a /dev/video1 (the latter is of course unusable, I don't have a MPEG > encoder chip on my card) but tuning was unsuccesful. All the other types > I tried either didn't work at all or only resulted in dvb devices > detected. For the moment, I am fine without DVB, and are interested > mainly in analog devices. > > Maybe I should locate the windows driver of my card and extract the > firmware files from it? If so, how do I proceed? > > Thanks in advance! > > Levente > > > > ___ > linux-dvb users mailing list > For V4L/DVB development, please use instead linux-media@vger.kernel.org > linux-...@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- 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
How to obtain sysfs-path from bus_info
Am Thu, 22 Jan 2009 22:12:08 +0100 schrieb Thierry Merle : > Laurent Pinchart a écrit : > > On Thursday 22 January 2009, Carsten Meier wrote: > >> Am Thu, 22 Jan 2009 00:20:00 +0100 > >> > >> schrieb Laurent Pinchart : > >>> Hi Carsten, > >>> > >>> On Wednesday 21 January 2009, Carsten Meier wrote: > now I want to translate bus_info into a sysfs-path to obtain > device-info like serial numbers. Given a device reports > "usb-:00:1d.2-2" as bus_info, then the device-info is located > under "/sys/bus/usb/devices/2-2", which is a symlink to the > appropriate /sys/devices/ directory, right? > >>> I'm afraid not. In the above bus_info value, :00:1d.2 is the > >>> PCI bus path of your USB controller, and the last digit after the > >>> dash is the USB device path. > >>> > All I have to do is to compare the first 4 chars of bus_info > against "usb-", get the chars after "." and append it to > "/sys/bus/usb/devices/" to obatin a sysfs-path, right? > > Is there a more elegant solution or already a function for this? > Can the "." appear more than once before the last one? > >>> Probably not before, but definitely after. > >>> > >>> Root hubs get a USB device path set to '0'. Every other device is > >>> numbered according to the hub port number it is connected to. If > >>> you have an external hub connected on port 2 of your root hub, > >>> and have a webcam connected to port 3 of the external hub, > >>> usb_make_path() will return "usb-:00:1d.2-2.3". > >>> > >>> Cheers, > >>> > >>> Laurent Pinchart > >> Hi, > >> > >> On my machine, my pvrusb2 (connected directly to my mini-pc) shows > >> up under "/sys/bus/usb/devices/7-2/" which is a symbolic link to > >> "../../../devices/pci:00/:00:1d.7/usb7/7-2" > > > > You're just lucky that USB bus 7 (usb7/7) is connected to the 7th > > function of your USB host controller (1d.7). > > > > Here's an example of what I get on my computer: > > > > /sys/bus/usb/devices/4-2 > > -> ../../../devices/pci:00/:00:1d.2/usb4/4-2 > > > >> I can't test for the new bus_info-string, because it's not fixed > >> yet in the driver. But if I got it correctly it should be > >> "usb-:00:1d.7-7.2" ? > > > > I think you will get usb-:00:1d.7-2 > > > >> Then I've to simply take the string after the last dash, replace > >> "." by "-" and append it to "/sys/bus/usb/devices/" for a > >> sysfs-path? > > > > Unfortunately the mapping is not that direct. The part before the > > last dash identifies the USB host controller. The part after the > > last dash identifies the device path related to the controller, > > expressed as a combination of port numbers. > > > > The sysfs device path /sys/bus/usb/devices/7-2/ includes a USB bus > > number (in this case 7) that is not present in usb_make_path()'s > > output. > > > > To find the sysfs path of your USB peripheral, you will have to > > find out which bus number the bus name (:00:1d.7) corresponds > > to. You might be able to find that by checking each usb[0-9]+ links > > in /sys/bus/usb/devices and comparing the link's target with the > > bus name. > > > To ease this processing, using libsysfs can be a good idea... > On my system, the documentation of libsysfs is here: > /usr/doc/sysfsutils-2.1.0/libsysfs.txt > Knowing the bus-id, it won't be hard to look at it in data structures. > Just my 2 cents. Hi, I already looked at it, but it doesn't help very much if you don't know how sysfs is organized in detail. The sysfs-reference at http://www.kernel.org/pub/linux/kernel/people/mochel/doc/papers/ols-2005/ also doesn't help very much as it only gives a brief overview. Regards, Carsten -- 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
How to obtain sysfs-path from bus_info
Am Thu, 22 Jan 2009 16:57:36 +0100 schrieb Laurent Pinchart : > On Thursday 22 January 2009, Carsten Meier wrote: > > Am Thu, 22 Jan 2009 00:20:00 +0100 > > > > schrieb Laurent Pinchart : > > > Hi Carsten, > > > > > > On Wednesday 21 January 2009, Carsten Meier wrote: > > > > now I want to translate bus_info into a sysfs-path to obtain > > > > device-info like serial numbers. Given a device reports > > > > "usb-:00:1d.2-2" as bus_info, then the device-info is > > > > located under "/sys/bus/usb/devices/2-2", which is a symlink to > > > > the appropriate /sys/devices/ directory, right? > > > > > > I'm afraid not. In the above bus_info value, :00:1d.2 is the > > > PCI bus path of your USB controller, and the last digit after the > > > dash is the USB device path. > > > > > > > All I have to do is to compare the first 4 chars of bus_info > > > > against "usb-", get the chars after "." and append it to > > > > "/sys/bus/usb/devices/" to obatin a sysfs-path, right? > > > > > > > > Is there a more elegant solution or already a function for > > > > this? Can the "." appear more than once before the last one? > > > > > > Probably not before, but definitely after. > > > > > > Root hubs get a USB device path set to '0'. Every other device is > > > numbered according to the hub port number it is connected to. If > > > you have an external hub connected on port 2 of your root hub, > > > and have a webcam connected to port 3 of the external hub, > > > usb_make_path() will return "usb-:00:1d.2-2.3". > > > > > > Cheers, > > > > > > Laurent Pinchart > > > > Hi, > > > > On my machine, my pvrusb2 (connected directly to my mini-pc) shows > > up under "/sys/bus/usb/devices/7-2/" which is a symbolic link to > > "../../../devices/pci:00/:00:1d.7/usb7/7-2" > > You're just lucky that USB bus 7 (usb7/7) is connected to the 7th > function of your USB host controller (1d.7). > > Here's an example of what I get on my computer: > > /sys/bus/usb/devices/4-2 > -> ../../../devices/pci:00/:00:1d.2/usb4/4-2 > > > I can't test for the new bus_info-string, because it's not fixed > > yet in the driver. But if I got it correctly it should be > > "usb-:00:1d.7-7.2" ? > > I think you will get usb-:00:1d.7-2 > > > Then I've to simply take the string after the last dash, replace > > "." by "-" and append it to "/sys/bus/usb/devices/" for a > > sysfs-path? > > Unfortunately the mapping is not that direct. The part before the > last dash identifies the USB host controller. The part after the last > dash identifies the device path related to the controller, expressed > as a combination of port numbers. > > The sysfs device path /sys/bus/usb/devices/7-2/ includes a USB bus > number (in this case 7) that is not present in usb_make_path()'s > output. > > To find the sysfs path of your USB peripheral, you will have to find > out which bus number the bus name (:00:1d.7) corresponds to. You > might be able to find that by checking each usb[0-9]+ links > in /sys/bus/usb/devices and comparing the link's target with the bus > name. > > Best regards, > > Laurent Pinchart Hi, I'll scan the link-targets of /sys/bus/usb/devices/usb[0-9] and compare them against the bus name. Now I've the problem of extracting the right path component of the link-target to compare with. E.g. /sys/bus/usb/devices/usb7 points to ../../../devices/pci:00/:00:1d.7/usb7 . My plan is to check the bus name against the component before last and then extract the bus num from the last component's digit. Now again a question: Does this always work or is there probably another parent directory for usb7 in the global devices-directory? Thanks again... Regards, Carsten -- 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] getting started with msi tv card
G'day Daniel, I just came up with a couple more ideas that could be worth mentioning, that you can keep in mind for the future... On Fri, 23 Jan 2009, BOUWSMA Barry wrote: > The other output format is `pids', and here's that from > back in 2006, before the use of the second audio channel > on the german broadcasters became widespread (last year): > > ZDF (0x6d66) 01: PCR == V V 0x006e A 0x0078 \ > (deu) 0x0079 (2ch) TT 0x0082 AC3 0x007d > > Here PID 0x79 is tagged as `2ch' (it's NAR for the Beeb), > and covers both audiodescription and occasional original- > language (mostly english language) broadcasts without > overdubbing. This was before DVB subtitles were introduced. > > Oh, here's an old BBC `pids' output, also including subtitles: > > BBC 1 London (0x189d) 01: PCR == V V 0x1388 A 0x1389 \ > (eng) 0x138a (NAR) TT 0x138b SUB 0x138c Now, I want to mention in detail the TT (teletext) and SUB (subtitle) services, at least, how they are implemented in this part of europe -- other parts of the world will likely be different, but my purpose is to throw around ideas in the hope that something will stick to the ceiling and be interesting and possibly useful. I mentioned that I find the nearly 100% penetration of subtitles to be quite useful to me personally, although it and in-field signing are intended for people whose hearing is not so good as mine, but whose vision is intact. The subtitles are sent in both a selected teletext page, as well as a separate DVB-subtitle stream. Unfortunately, the support that `mplayer' has for DVB subtitles last I knew, is, well, bad to none, and basically requires completely rewriting that bit. `xine' worked better some months ago, but at that time had some timing problems. Anyway, as I understand it, DVB subtitles are sent as bitmaps, which unfortunately makes it difficult for you to use them. This also explains the difference in appearance between the BBC subtitles and those of ITV. However, I haven't seen mangled fonts due to transmission errors, while I have seen incorrect yet properly-formed characters at times. So my understanding of DVB subtitles is far from complete or correct. Standard teletext, as was introduced with analogue transmissions as part of the vertical blanking interval, has been carried over to DVB broadcasts. In the case of the BBC, this is mostly limited to subtitles on page 888, while the german services I've mentioned offer full text services, occasionally including subtitles, but on a limited set of programmes. Only the ZDF has both teletext and DVB subtitles at present, of the german public broadcasters. These DVB subtitle fonts again differ in appearance from any of the british public broadcasters. In the UK, the move has been away from conventional teletext with the introduction of digital services, replacing it with an MHEG-based service. In germany, there has been a push to supplement regular teletext with an MHP-based service, but for lack of interest and readily-available hardware, this has pretty much died out or stagnated. I seem to recall that in Australia, use is made of an MHEG service. I don't know if a regular teletext service is available -- you will see this in the results, when you have a tuner capable of scanning. Now, ideally, a teletext service, being text-based, can be trivially converted to braille or spoken. I'm not sure about the MHEG services, as they seem to place more importance on the on-screen appearance, yet they do use a TrueType font. Anyway, while conventional teletext is not simple ASCII-like, it is based on a hamming of a limited character set which can be converted back to a standard 128- or 256-character set font, and of course the normal characters can be displayed as braille. Now, here is an example of some of the useful information to be found on a full teletext service, to show that, if it were available to you, you might find it interesting. This is a page giving inter-bank exchange rates from the Euro to your own currency, and is meant as an example (it's in german, but should be trivial to understand) /GIP IG*** PHOENIX Mi 21.01.09 18:01:45 PHOENIX.text 2/2 Devisenkurse Letzte DatenabfrageDiff. Kurs- 21.01.09, 18:00 UhrVortag zeit USA... (USD) 1,2857 -0,20% 17:59 GB (GBP) 0,9369 +0,94% 17:59 Schweiz... (CHF) 1,4767 -0,13% 17:59 Japan. (JPY) 112,9800 -2,35% 17:59 Kanada (CAD) 1,6365 +0,37% 17:59 Südafrika. (ZAR) 13,0970 -1,05% 17:50 Hongkong.. (HKD) 9,9990 +0,07% 17:49 Singapur.. (SGD) 1,9401 -0,13% 17:50 Australien (AUD) 1,9804 -0,23% 17:59
Re: How can I fix errors and warnings in nvidia module for Tesla C1060
On Friday 23 January 2009, Jaswinder Singh Rajput wrote: > Hello, > > I am trying to install driver of nvidia Tesla C1060 on x86 based > compute node of Rockcluster 5.1 > > But I am following errors and warnings: > >make -f /usr/src/kernels/2.6.18-92.1.13.el5-i686/scripts/Makefile.build > obj= >/tmp/selfgz3379/NVIDIA-Linux-x86-177.72-pkg1/usr/src/nv > cc > -Wp,-MD,/tmp/selfgz3379/NVIDIA-Linux-x86-177.72-pkg1/usr/src/nv/.nv.o.d > -nostdinc -isystem /usr/lib/gcc/i386-redhat-linux/4.1.2/include > -D__KERNEL_ >_ -Iinclude -Iinclude2 -I/usr/src/kernels/2.6.18-92.1.13.el5-i686/include > -i >nclude include/linux/autoconf.h > -I/tmp/selfgz3379/NVIDIA-Linux-x86-177.72- >pkg1/usr/src/nv -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs > -fno-strict >-aliasing -fno-common -Wstrict-prototypes -Wundef > -Werror-implicit-function- >declaration -Os -pipe -msoft-float -fno-builtin-sprintf -fno-builtin-log2 > -f >no-builtin-puts -mpreferred-stack-boundary=2 -march=i686 -mtune=generic > -mtu >ne=generic -mregparm=3 -ffreestanding > -I/usr/src/kernels/2.6.18-92.1.13.el5- >i686/include/asm-i386/mach-generic -Iinclude/asm-i386/mach-generic > -I/usr/sr >c/kernels/2.6.18-92.1.13.el5-i686/include/asm-i386/mach-default > -Iinclude/as >m-i386/mach-default -fomit-frame-pointer -g -fno-stack-protector > -Wdeclarati >on-after-statement -Wno-pointer-sign -I/tmp/self >gz3379/NVIDIA-Linux-x86-177.72-pkg1/usr/src/nv -Wall -Wimplicit > -Wreturn-typ >e -Wswitch -Wformat -Wchar-subscripts -Wparentheses -Wpointer-arith > -Wno-mul >tichar -Werror -MD -Wsign-compare -Wno-cast-qual -Wno-error -D__KERNEL__ > -DM >ODULE -DNVRM -DNV_VERSION_STRING=\"177.72\" -UDEBUG -U_DEBUG -DNDEBUG > -DMODU >LE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(nv)" > -D"KBUILD_MODNAM >E=KBUILD_STR(nvidia)" -c -o > /tmp/selfgz3379/NVIDIA-Linux-x86-177.72-pkg1/usr >/src/nv/.tmp_nv.o > /tmp/selfgz3379/NVIDIA-Linux-x86-177.72-pkg1/usr/src/nv/nv >.c >In file included from include/linux/list.h:8, > from include/linux/lockdep.h:13, > from include/linux/spinlock_types.h:18, > from include/linux/spinlock.h:78, > from include/linux/capability.h:45, > from include/linux/sched.h:44, > from include/linux/module.h:9, > from > /tmp/selfgz3379/NVIDIA-Linux-x86-177.72-pkg1/usr/src/n >v/nv-linux.h:59, > from > /tmp/selfgz3379/NVIDIA-Linux-x86-177.72-pkg1/usr/src/n >v/nv.c:14: >include/linux/prefetch.h: In function 'prefetch_range': >include/linux/prefetch.h:62: warning: pointer of type 'void *' used in > arith >metic >In file included from include/linux/dmapool.h:14, > from include/linux/pci.h:616, > from > /tmp/selfgz3379/NVIDIA-Linux-x86-177.72-pkg1/usr/src/n >v/nv-linux.h:86, > from > /tmp/selfgz3379/NVIDIA-Linux-x86-177.72-pkg1/usr/src/n >v/nv.c:14: >include/asm/io.h: In function 'check_signature': >include/asm/io.h:245: warning: wrong type argument to increment > > ... > > -> Kernel module compilation complete. > ERROR: Unable to load the kernel module 'nvidia.ko'. This happens most >frequently when this kernel module was built against the wrong or >improperly configured kernel sources, with a version of gcc that > differs >from the one used to build the target kernel, or if a driver such as >rivafb/nvidiafb is present and prevents the NVIDIA kernel module from >obtaining ownership of the NVIDIA graphics device(s). > >Please see the log entries 'Kernel module load error' and 'Kernel >messages' at the end of the file '/var/log/nvidia-installer.log' for >more information. > -> Kernel module load error: insmod: error inserting './usr/src/nv/nvidia.ko': >-1 No such device > > I am attaching complete log file for your reference. > > I cannot see any source code for these modules. How can I fix these > error and warnings. That's likely because the NVidia driver expects the arch asm headers to be in include/linux . Thanks, Rafael -- 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
