Re: [linux-dvb] RFC - Flexcop Streaming watchdog (VDSB)
Hi Barry, Hi Walter, On Sat, 17 Jan 2009, BOUWSMA Barry wrote: For years there has been the Video Data Stream Borken-error with VDR and Technisat cards: The error occured randomly and unfrequently. A In fact it turned out, that the problem is worse with setups not based on VDR and the VDSB-error could be really easily reproduced (I'm not sure if this applies to all generations on SkyStar2-card). I'm Which generation of cards have this problem? I did not see any VDSB with my two Skystar 2.6D. Same here -- never experienced this ever in some four-ish years with one SkyStar2 of model long forgotten, with that card being the primary one used whenever possible... (in use typically several times per day, sometimes half a day uninterrupted, but on a production machine at 2.6.14-ish) Using VDR or a single application (like kaffeine), you most likely don't see the error anymore thanks to the work-around which is already in place. It is resetting the streaming interface at the end of a streaming-session, ie. when the pid-filter count is going from 1 to 0. This happens all the time with VDR (and similar) when it is retuning. Now when you launch an application which is just requesting a pid and another one which is tuning independently, you can fall easily in this problem. I have to say, that the user which showed me the problem was using the rev2.8 and due to the lack of time I couldn't check with other versions than this card yet. But I think those kind of problems also exist for older cards. Patrick. PS: how to reproduce: shell 1: $ tzap channel shell 2: $ dvbtraffic [lots of output that streaming is working] shell 1: $ C-c shell 1: $ tzap channel2_which is on a different frequency shell 2: no output of dvbtraffic any longer... (problem) -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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: MC44S803 frontend (it works)
Hi Antti, thanks for your work. I unpacked mc44s803-b7ac1c462be3 and tried to run make install as root since I wanted to update my kernel modules. This did not work. On the other hand running only make finished with some warnings but no errors. My kernel is 2.6.27-11-generic from Ubuntu 8.10. The system is up to date. These tries I performed on a newly installed Linux where I never tried running my DVB-T stick (TerraTec Electronic GmbH Cinergy T XE DVB-T Receiver, MKII) under Linux before. Have installed VMware on this machine and can use the stick without problems in a WXP-Pro VM. Can you please give an advice what I should do next? I wo'nt destroy my running system. Best regards, Detlef Antti Palosaari schrieb: Hello I just pushed Jochen's MC44S803 driver to linuxtv.org devel tree. I did some changes to patch that adds this tuner to AF9015, because patch didn't applied and also some other changes. Hopefully it doesn't break functionality. Please test. http://linuxtv.org/hg/~anttip/mc44s803/ regards Antti -- 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: MC44S803 frontend (it works)
Hi Antti, I did some more changes, could you test again: This version works OK for me :-). The old version also worked, but was very insensitive (i only received one transponder instead of 6, i guess this GPIO must switch on some RF-amplifyer or so). Thanks, Jochen -- 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] RFC - Flexcop Streaming watchdog (VDSB)
On Sat, 17 Jan 2009, Patrick Boettcher wrote: Same here -- never experienced this ever in some four-ish years with one SkyStar2 of model long forgotten, with that card being Using VDR or a single application (like kaffeine), you most likely don't see the error anymore thanks to the work-around which is already in place. It is resetting the streaming interface at the end of a streaming-session, ie. when the pid-filter count is going from 1 to 0. This happens all the time with VDR (and similar) when it is retuning. Okay, I've been using `dvbstream' standalone, also modified so that it and related utilities get an exclusive lock on the adapter (otherwise when I'd make a mistake, the second invocation of `dvbstream' would not only fail, but the first recording was also messed up, so less than useless). `scan' has also been used, although in my latest installation (including a 12-output multiswitch), the card I have has been unable to lock or to get error-free output from transponders at the ends of the frequency range -- this affects at Astra 19E2 the ORF transponders among others, and at 28E many of the Channel 4 family, while all other devices on the same multiswitch have no difficulties at even higher frequencies and can scan the entire range perfectly. I've also guessed this could be due to spiders taking up residence in the warm interior of the tuning circuits. Anyway, someday I'll replace this card with an -S2 or perhaps dual- hybrid- whatever is available later. Now when you launch an application which is just requesting a pid and another one which is tuning independently, you can fall easily in this problem. PS: how to reproduce: shell 1: $ tzap channel shell 2: $ dvbtraffic [lots of output that streaming is working] shell 1: $ C-c shell 1: $ tzap channel2_which is on a different frequency shell 2: no output of dvbtraffic any longer... (problem) This lack-of-output is something that I've experienced with other cards (a dvb-usb DVB-T device), which I did not investigate further. If I remember rightly, and with a more recent kernel. Note that in my `dvbstream'-exclusively use of the SkyStar2, I have never seen the error message (since trimmed from the quoted original post). I'll see if I can reproduce this on my production machine once it's idle, or if my hacks might be involved, and report back about this... thanks 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
Compile warning for CX18 / v4l2-common Ubuntu 8.10
A pull from v4l-dvb today: Kernel build directory is /lib/modules/2.6.27-7-generic/build make -C /lib/modules/2.6.27-7-generic/build SUBDIRS=/root/drivers/v4l-dvb/v4l modules make[2]: Entering directory `/usr/src/linux-headers-2.6.27-7-generic' ... /opt/drivers/v4l-dvb/v4l/cx18-driver.c: In function 'cx18_request_module': /opt/drivers/v4l-dvb/v4l/cx18-driver.c:735: warning: format not a string literal and no format arguments CC [M] /root/drivers/v4l-dvb/v4l/v4l2-common.o /root/drivers/v4l-dvb/v4l/v4l2-common.c: In function 'v4l2_ctrl_query_fill': /root/drivers/v4l-dvb/v4l/v4l2-common.c:559: warning: format not a string literal and no format arguments /root/drivers/v4l-dvb/v4l/v4l2-common.c: In function 'v4l2_ctrl_query_menu': /root/drivers/v4l-dvb/v4l/v4l2-common.c:724: warning: format not a string literal and no format arguments /root/drivers/v4l-dvb/v4l/v4l2-common.c: In function 'v4l2_ctrl_query_menu_valid_items': /root/drivers/v4l-dvb/v4l/v4l2-common.c:742: warning: format not a string literal and no format arguments /root/drivers/v4l-dvb/v4l/v4l2-common.c: In function 'v4l2_i2c_new_subdev': /root/drivers/v4l-dvb/v4l/v4l2-common.c:947: warning: format not a string literal and no format arguments /root/drivers/v4l-dvb/v4l/v4l2-common.c: In function 'v4l2_i2c_new_probed_subdev': /root/drivers/v4l-dvb/v4l/v4l2-common.c:1008: warning: format not a string literal and no format arguments Thanks, Brandon -- 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] RFC - Flexcop Streaming watchdog (VDSB)
Patrick, Please ignore my comment prior in this thread about using spin_lock_irq() vs. spin_lock_irqsave(). Between lack of sleep and trying to install Fedora 10 and recover my data on what now appears to be a failing motherboard/cpu, I made an error. I realized spinlock functions should always disable local IRQs (*smacks forehead*). What one has to take care with is unconditionally re-enabling local IRQs with spin_unlock_irq(). One would think that a work handler is known to be called in a non-irq context. So, at the risk of being wrong again, using spin_unlock_irq() should be OK, if spin_lock_irq() is allowed by the kernel in a work handler context (which your experimentation indicates that it is not). 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: MC44S803 frontend (it works)
Antti Palosaari wrote: Tahnks, I did some more changes, could you test again: http://linuxtv.org/hg/~anttip/mc44s803/ Tested here. Works perfectly. -- Roberto Ragusamail at robertoragusa.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: Compile warning for CX18 / v4l2-common Ubuntu 8.10
On Saturday 17 January 2009 13:34:05 Brandon Jenkins wrote: A pull from v4l-dvb today: Kernel build directory is /lib/modules/2.6.27-7-generic/build make -C /lib/modules/2.6.27-7-generic/build SUBDIRS=/root/drivers/v4l-dvb/v4l modules make[2]: Entering directory `/usr/src/linux-headers-2.6.27-7-generic' ... /opt/drivers/v4l-dvb/v4l/cx18-driver.c: In function 'cx18_request_module': /opt/drivers/v4l-dvb/v4l/cx18-driver.c:735: warning: format not a string literal and no format arguments CC [M] /root/drivers/v4l-dvb/v4l/v4l2-common.o /root/drivers/v4l-dvb/v4l/v4l2-common.c: In function 'v4l2_ctrl_query_fill': /root/drivers/v4l-dvb/v4l/v4l2-common.c:559: warning: format not a string literal and no format arguments /root/drivers/v4l-dvb/v4l/v4l2-common.c: In function 'v4l2_ctrl_query_menu': /root/drivers/v4l-dvb/v4l/v4l2-common.c:724: warning: format not a string literal and no format arguments /root/drivers/v4l-dvb/v4l/v4l2-common.c: In function 'v4l2_ctrl_query_menu_valid_items': /root/drivers/v4l-dvb/v4l/v4l2-common.c:742: warning: format not a string literal and no format arguments /root/drivers/v4l-dvb/v4l/v4l2-common.c: In function 'v4l2_i2c_new_subdev': /root/drivers/v4l-dvb/v4l/v4l2-common.c:947: warning: format not a string literal and no format arguments /root/drivers/v4l-dvb/v4l/v4l2-common.c: In function 'v4l2_i2c_new_probed_subdev': /root/drivers/v4l-dvb/v4l/v4l2-common.c:1008: warning: format not a string literal and no format arguments I've never seen these warnings, but they seem to be caused by snprintf(dst, size, src), without a proper format string. By itself harmless, but replacing it with strlcpy is better. I did that for v4l2-common.c, but I don't see something similar in cx18_request_module. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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[3]: [linux-dvb] dvb-t config for Ukraine_Kiev (ua)
Hello Dmitry, I am pleased that I was able to help you! But there is one thing that caught my interest, so I am again posting this question to the -dvb mailing list, and I guess to linux-media too: On Fri, 16 Jan 2009, vdp wrote: But when I add -tm8 (THANK YOU FOR AUDIT ): it start dvbstream -tm 8 -c 0 -I 2 -qam 64 -gi 32 -cr 2_3 -bw 8 -f 65000 -net 224.12.12.12:1234 4311 4312 tuning DVB-T (in United Kingdom) to 65000 Hz, Bandwidth: 8 To the readers of the list, and of linux-media, the default of `dvbstream' here is to use FFT transmission mode 2k, as was introduced in the UK, and it's clear how UK-centric this utility is based on the above line. (UK not meaning UA or Ukraine) Now as part of DSO in the UK, the multiplexes are slowly to convert from 2k to 8k, and most other parts of the world are presently using 8k. In fact, as I `grep' the latest dvb-apps scan files, only the UK sites listed seem to be using 2k, for now. Does anyone familiar with DVB-T know whether 2k transmission mode is used elsewhere in the world? If not, would it not be reasonable to default to 8k for this code, to make it applicable to the parts of the UK that have switched as well as most of the rest of the world? Reading the CVS RCS files, this doesn't seem to have been updated for several years, and presumably distributed binary packages are using the UK defaults, the code of which seems unchanged from 2002, so I imagine this could use reworking. wonderful word !!! You, from other country help me, real-time and free It is indeed my pleasure. While I have not made a visit to your country, with the closest being in Košice, SK, I prefer to think that we are in the same part of the world, with much in common... with best regards, Dmitry Odessa, Ukraine Now, back to the original subject of this message, a scanfile for Kиïв, with proper modulation values... Can you run the following commands for me, then send me the files in /tmp/stream-* so that I can verify the modulation? These will record three seconds worth of the NIT data with the modulation, into several small files in /tmp, for all the different multiplexes. First, the command you used above to stream 5 ĸaнaл : dvbstream -tm 8 -c 0 -I 2 -qam 64 -gi 32 -cr 2_3 -bw 8 \ -f 65000 -o:/tmp/stream-650.ts -n 3 16 Now try it with the other frequencies and see if you still can lock: dvbstream -tm 8 -c 0 -I 2 -qam 64 -gi 32 -cr 3_4 -bw 8 \ -f 63400 -o:/tmp/stream-634.ts -n 3 16 dvbstream -tm 8 -c 0 -I 2 -qam 64 -gi 32 -cr 2_3 -bw 8 \ -f 71400 -o:/tmp/stream-714.ts -n 3 16 dvbstream -tm 8 -c 0 -I 2 -qam 64 -gi 32 -cr 2_3 -bw 8 \ -f 81800 -o:/tmp/stream-818.ts -n 3 16 And last, a frequency where the services are in MPEG-4: dvbstream -tm 8 -c 0 -I 2 -qam 64 -gi 32 -cr 2_3 -bw 8 \ -f 68200 -o:/tmp/stream-682.ts -n 3 16 If you have success, then you can send me all the files in /tmp/stream-*.ts, and I will look at them, make sure that all the data in the scanfile is correct, and confirm it to Christoph Pfister... thanks, 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: KWorld ATSC 115 all static
On Friday 16 January 2009 04:20:02 CityK wrote: 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. If you try to run 'modprobe -r tuner' when the saa7134 module build from my sources is loaded, then that should not work since saa7134 increases the use-count of the tuner module preventing it from being unloaded. If you can do this, then that suggests that you are perhaps not using my modified driver at all. BTW, I've asked Mauro to pull from my tree (www.linuxtv.org/hg/~hverkuil/v4l-dvb) which contains the converted saa7134 and saa6752hs drivers. It's definitely something that needs to be done regardless. Regards, Hans In fact, as similar to the results reported in the previous message, performing such action produces no result in dmesg. -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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?
Hello, Am Donnerstag, den 15.01.2009, 20:08 -0500 schrieb 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 thanks! It reflects the current situation quite well. 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!) Gunther's listing about what a report for a new card should contain is still fine and might be a guideline on the wiki too. Luckily we get the eeprom content of most drivers these days in dmesg. How much we can do already with it then is another question, but in most cases we get already hints about the tuner type and address, both are most often vendor specific, also about addresses of analog and digital demods, there is duplicate stuff for different devices, and also second digital tuners and demods. Many drivers have an i2cscan=1 option, modinfo driver module, which can discover some chips, as long they are not behind i2c gates, but such chips are often visible in the eeprom. The i2c_scan should be enabled for a report. How to open a can tuner was also important for the flood of unknown and undocumented such tuners in the past. This is still an issue with current silicon devices, since some RF shielding is often soldered around them, but most manufacturers make the top cover removable now, what unfortunately was not possible in the past and did set the users at high risk to destroy their devices upon discovering what is hidden. The bttv-gallery was more an information collection for hackers, the actual status of a device then you got on the lists and with the code. Most of the time it
[cron job] ERRORS: 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:Sat Jan 17 19:00:04 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 10241:7981bdd4e25a 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: ERRORS linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29-rc2-armv5-ixp: ERRORS linux-2.6.27-armv5-omap2: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29-rc2-armv5-omap2: ERRORS linux-2.6.16.61-i686: OK linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: WARNINGS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29-rc2-i686: ERRORS 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: ERRORS linux-2.6.16.61-mips: OK linux-2.6.26-mips: WARNINGS linux-2.6.27-mips: WARNINGS linux-2.6.28-mips: WARNINGS linux-2.6.29-rc2-mips: ERRORS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29-rc2-powerpc64: ERRORS linux-2.6.16.61-x86_64: OK linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.11-x86_64: WARNINGS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: WARNINGS linux-2.6.28-x86_64: WARNINGS linux-2.6.29-rc2-x86_64: ERRORS 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/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.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] Where to buy a Dual PCI-e DVB-s2 card in switzerland ?
(Feckin' Reply-To header makes it difficult to send a personal reply as well as a followup to the desired place... Grrr...) On Sat, 17 Jan 2009, Gregoire Favre wrote: Igor Liplianin just announced support for XpressVu PCIe Dual Tuner Card and I was wondering where I could buy one, preferably in Switzerland. Seems that it is not yet widely available... Can I assume you are in the Suisse Romande, and somewhat far from Germany/Basel, or perhaps somewhere like Zürich? You can often save enough and get Mwst back if you shop over the border. Feel free to respond privately if you do not wish to make your location public... In any case, I would suggest perhaps waiting a few weeks, and then seeing where it can be found in various online shops and price comparison sites... 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: RFC: Where to store camera properties (upside down, needs sw whitebalance, etc). ?
On Fri, 16 Jan 2009, Olivier Lorin wrote: snip Post gamma or white balance correction seemed to be more part of the webcam capabilities than the image state so that the new API to get these features is quite logical. Hmmm. While one is in the process of planning ahead, it it good to think of everything. You have not yet seen any code for the sq905c cameras in webcam mode, yet. Well, actually, you can if you want to. The needed sequence of operations is used in the support for gphoto2 --capture-preview in libgphoto2/camlibs/digigr8/library.c. What happens with this camera is, the frame data has been compressed and therefore it is needed to know how much data is present for a frame before downloading the rest of the frame. The length of the frame header is set at 0x50 bytes, so one downloads that first. Here is a sample of one such frame header: ff 00 ff 00 ff 00 ff 00-ff 00 ff 00 ff 00 ff 00 0010 ff 00 ff 00 ff 00 ff 00-ff 00 ff 00 ff 00 ff 00 0020 ff 00 ff 00 ff 00 ff 00-ff 00 ff 00 ff 00 ff 00 0030 ff 00 ff 00 ff 00 ff 00-ff 00 ff 00 ff 00 ff 00 0040 e0 5a 00 00 3b 3e 50 3b-36 00 ff 00 ff 00 ff 00 .Z..;P;6... Now, most of this is just filler. The data size for the frame is to be found in bytes 0x40 and 0x41 and it says that 0x5ae0 bytes must be downloaded for this frame. I have never seen the next two bytes with anything in them, so my reasonable conjecture is that they are similarly used, as part of the data size field. It is just that in practice one never sees a frame with so much data in it. Now, my comment here is directed toward bytes 0x44 through 0x48. I do not claim to know exactly what they mean. However, I would strongly suspect that they have something to do with contrast, color balance, intensity, and so on. Really, logic would seem to indicate that there is no other point to providing those entries, which certainly do vary from one frame to another and the readings in them do seem in some vague sense to have something to do with the local light conditions, and sucn. Therefore, confronted with my experience with these cameras, I would tend to suspect that Post gamma or white balance correction seemed to be more part of the webcam capabilities than the image state may not always be the case. For, here, with this camera, it appears that some kind of related information is being passed with each individual frame. It is also more certainly the case that the camera has no other way to pass such information. In particular, there is no long initialization sequence. One just turns on the stream. Theodore Kilgore -- 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
Am Samstag, den 17.01.2009, 13:44 -0500 schrieb Michael Krufky: hermann pitton wrote: Hi, Am Samstag, den 17.01.2009, 17:20 +0100 schrieb Hans Verkuil: On Friday 16 January 2009 04:20:02 CityK wrote: 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. If you try to run 'modprobe -r tuner' when the saa7134 module build from my sources is loaded, then that should not work since saa7134 increases the use-count of the tuner module preventing it from being unloaded. If you can do this, then that suggests that you are perhaps not using my modified driver at all. BTW, I've asked Mauro to pull from my tree (www.linuxtv.org/hg/~hverkuil/v4l-dvb) which contains the converted saa7134 and saa6752hs drivers. It's definitely something that needs to be done regardless. Hans, Mauro has pulled them in already. For my report for the old issue with the tda9987 not loaded for the md7134 card=12 with eeprom tuner detection and all the types with FMD1216ME MK3 hybrid subsumed there beside the older ones with analog only tuners (CTX917/918/925triple/946mpeg/921cardbus), the users must just unload the saa7134 and tuner modules and then load tda9887 and tuner before the saa7134 for now. That's not possible -- tda9887 is now a sub-module of tuner-core. tda9887, when modprobed alone, will not attach to any actual device without also having tuner.ko loaded in memory. tda9887 is a separate module, but its interface is currently only accessed via tuner-core (tuner.ko) -Mike Mike, please look. You can see that the previously not loaded tda9887 is present and initialized now. Cheers, Hermann [r...@pc10 ~]# modprobe -vr saa7134-dvb rmmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/saa7134/saa7134-dvb.ko rmmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/videobuf-dvb.ko rmmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/dvb/dvb-core/dvb-core.ko rmmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/saa7134/saa7134.ko rmmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/common/ir-common.ko rmmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/tveeprom.ko rmmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/videobuf-dma-sg.ko rmmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/videobuf-core.ko [r...@pc10 ~]# modprobe -vr tda9887 tuner tuner-simple rmmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/tuner.ko rmmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/v4l2-common.ko rmmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/videodev.ko rmmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/v4l1-compat.ko rmmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/common/tuners/tuner-simple.ko rmmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/common/tuners/tuner-types.ko [r...@pc10 ~]# modprobe -v tda9887 insmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/common/tuners/tda9887.ko [r...@pc10 ~]# modprobe -v tuner insmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/v4l1-compat.ko insmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/videodev.ko insmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/v4l2-common.ko insmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/tuner.ko [r...@pc10 ~]# modprobe -v saa7134 insmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/tveeprom.ko insmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/videobuf-core.ko insmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/videobuf-dma-sg.ko insmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/common/ir-common.ko insmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/saa7134/saa7134.ko latency=64 gbuffers=32 [r...@pc10 ~]# dmesg Initializing cgroup subsys cpuset Linux version 2.6.26.6-49.fc8 (mockbu...@x86-2.fedora.phx.redhat.com) (gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)) #1 SMP Fri Oct 17 15:59:36 EDT
[PATCH] Bttv: move check on unsigned
Please review, this patch was not tested.
The static function set_tvnorm is called in
drivers/media/video/bt8xx/bttv-driver.c:
1355: set_tvnorm(btv, norm);
1868: set_tvnorm(btv, i);
3273: set_tvnorm(btv,btv-tvnorm);
in the first two with an unsigned, but bttv-tvnorm is signed.
see vi drivers/media/video/bt8xx/bttvp.h +381
since norm is unsigned in set_tvnorm, a negative won't get noticed.
so remove the redundant check and move it to the caller.
My question is: should we error return like this?
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
diff --git a/drivers/media/video/bt8xx/bttv-driver.c
b/drivers/media/video/bt8xx/bttv-driver.c
index c71f394..6f50f90 100644
--- a/drivers/media/video/bt8xx/bttv-driver.c
+++ b/drivers/media/video/bt8xx/bttv-driver.c
@@ -1290,7 +1290,7 @@ set_tvnorm(struct bttv *btv, unsigned int norm)
const struct bttv_tvnorm *tvnorm;
v4l2_std_id id;
- if (norm 0 || norm = BTTV_TVNORMS)
+ if (norm = BTTV_TVNORMS)
return -EINVAL;
tvnorm = bttv_tvnorms[norm];
@@ -3266,6 +3266,10 @@ static int bttv_open(struct file *file)
V4L2_FIELD_SEQ_TB,
sizeof(struct bttv_buffer),
fh);
+ if (btv-norm 0) {
+unlock_kernel();
+return -EINVAL;
+}
set_tvnorm(btv,btv-tvnorm);
set_input(btv, btv-input, btv-tvnorm);
--
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:19 +0100, Sam Ravnborg wrote: Nope - include/linux/dvb/audio.h failed to include linux/types.h despite the fact that is uses __u32 etc. Er, good point. I saw the stdint.h and assumed it was using only proper C types... but then it wouldn't have triggered the warning, would it? Too much time in tin cans and not enough sleep... -- dwmw2 -- 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
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. stdint.h is one of a handful of headers provided by gcc itself. -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: [linux-dvb] Problem with video4linux
Hello Mauro, After using the mythtv setup for a few days now with kernel 2.6.27.9-159.fc10.i686 and v4l modules from 2009-01-06 as well as 2009-01-16 I have noticed some problems with sound . I use exclusively optical spdiff passthrough from my motherboard asus 5b (intel chips for audio) to the AV Receiver for audio . And with either of those two v4l sources are installed I start getting no audio on the spdif . Without them , using the dvb support that comes with the kernel all is ok . Maybe it could be related to that ALSA issue ? Could you please tell me which svn pull of the v4l source the 2.6.27.9-159.fc10.i686 kernel comes with ? In the last six months there have been a lot of changes to the dvbs api , and knowing what the kernel comes with would help me compile additional sw that I need for my myth box . Otherwise it involves a lot of trial and error . Best Regards Milorad -- 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: [PATCHv4] Add Freescale MC44S803 tuner driver
Hi All, I have to apologize being a stupid newbie not able to put Antti's latest source (mc44s803-71b0ef33303a) into my kernel (2.6.27-11-generic). Have performed successfully a make, but running install failed because of missed option settings for this operation. I am uncertain if I must set a path directory. Is'nt there a symbolic link to the right directory? make compiled lots of not needed stuff here, but my system needs only a firmware file: (Copied from /var/log/messages) Jan 17 23:22:21 detlef-laptop kernel: [ 155.512517] dvb-usb: found a 'TerraTec Cinergy T USB XE' in cold state, will try to load a firmware Jan 17 23:22:21 detlef-laptop kernel: [ 155.512530] firmware: requesting dvb-usb-af9015.fw Jan 17 23:22:21 detlef-laptop kernel: [ 155.526289] dvb_usb_af9015: probe of 4-3.3:1.0 failed with error -2 Maybe Antti can post me one which I simply can paste into /lib/firmware? Hopefully one of you can give an advice.. regards, Detlef Antti Palosaari schrieb: 2.6.27-11-generic Hello Jochen, I just reviewed this patch and here is my comments; Jochen Friedrich wrote: +buf[0] = (val 0xFF) 16; I am not sure where it comes I have seen comments sometimes that we should use lower case hex numbers. +return -EREMOTEIO; [...] +u8 ret, id; Error status (-EREMOTEIO) is stored to the u8, which leads ~254. This seems not to be problem currently because mc44s803_readreg() is used only in mc44s803_attach() that returns NULL in error case. Anyhow, I think it would be better to use int for clarity. regards, Antti -- 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
Analog TV on Leadtek PxDVR 3200 H
Hello, I have a problem with module cx23885, it doesn't create the /dev/video0 device. My config: Leadtek PxDVR 3200 H Analog/DVB card Linux - Fedora 10 (2.6.27.9-159.fc10.x86_64) V4L/DVB repository from http://linuxtv.org/hg/v4l-dvb as the TV card is not supported by the distro kernel drivers. I have an analog signal (DVB in 2010). I compiled the v4l/dvb kernel modules against kernel headers and installed. Then I depmod'ed new modules, removed all old v4l modules (rmmod) and inserted new ones (modprobe). The card was detected, but there is no /dev/video0 device, only /dev/dvb/adapter0/demux0,dvr0,frontend0,net0. So I cannot run tvtime or any other tv application which tries to open /dev/video0. (opening /dev/dvd/adapter0/whatever doesn't help). How can I make it creating /dev/video0 device? Regards, Martin Here is my dmesg debug output from cx23885 # modprobe cx23885 debug=1 v4l_debug=1 i2c_debug=1 vbi_debug=1 video_debug=1 Jan 18 01:56:45 htpc1 kernel: cx23885 driver version 0.0.1 loaded Jan 18 01:56:45 htpc1 kernel: cx23885 :04:00.0: PCI INT A - Link[LN2A] - GSI 18 (level, low) - IRQ 18 Jan 18 01:56:45 htpc1 kernel: CORE cx23885[0]: subsystem: 107d:6681, board: Leadtek Winfast PxDVR3200 H [card=12,autodetected] Jan 18 01:56:45 htpc1 kernel: W 88 017cx23885[0]/0: 017cx23885[0]/0: Jan 18 01:56:45 htpc1 kernel: W 88 017cx23885[0]/0: 007cx23885[0]/0: Jan 18 01:56:45 htpc1 kernel: cx25840' 2-0044: cx25 0-21 found @ 0x88 (cx23885[0]) Jan 18 01:56:45 htpc1 kernel: W 88 087cx23885[0]/0: d47cx23885[0]/0: Jan 18 01:56:45 htpc1 kernel: W 88 017cx23885[0]/0: 607cx23885[0]/0: 1d7cx23885[0]/0: Jan 18 01:56:45 htpc1 kernel: W 88 017cx23885[0]/0: 647cx23885[0]/0: 007cx23885[0]/0: Jan 18 01:56:45 htpc1 kernel: W a0 00 Jan 18 01:56:45 htpc1 kernel: 207cx23885[0]/0: 007cx23885[0]/0: 137cx23885[0]/0: 007cx23885[0]/0: 007cx23885[0]/0: 007cx23885[0]/0: 007cx23885[0]/0: 007cx23885[0]/0: 207cx23885[0]/0: 007cx23885[0]/0: 137cx23885[0]/0: 007cx23885[0]/0: 007cx23885[0]/0: 007cx23885[0]/0: 007cx23885[0]/0: 007cx23885[0]/0: 207cx23885[0]/0: 007cx23885[0]/0: 137cx23885[0]/0: 007cx23885[0]/0: 007cx23885[0]/0: 007cx23885[0]/0: 007cx23885[0]/0: 007cx23885[0]/0: 207cx23885[0]/0: 007cx23885[0]/0: 137cx23885[0]/0: 007cx23885[0]/0: 007cx23885[0]/0: 007cx23885[0]/0: 007cx23885[0]/0: 007cx23885[0]/0: 087cx23885[0]/0: 007cx23885[0]/0: 187cx23885[0]/0: 037cx23885[0]/0: 007cx23885[0]/0: 007cx23885[0]/0: 037cx23885[0]/0: 9d7cx23885[0]/0: 0c7cx23885[0]/0: 037cx23885[0]/0: 057cx23885[0]/0: 007cx23885[0]/0: 0e7cx23885[0]/0: 017cx23885[0]/0: 007cx23885[0]/0: 007cx23885[0]/0: 207cx23885[0]/0: 007cx23885[0]/0 Jan 18 01:56:45 htpc1 kernel: : 137cx23885[0]/0: 007cx23885[0]/0: 007cx23885[0]/0: 007cx23885[0]/0: 007cx23885[0]/0: 007cx23885[0]/0: 507cx23885[0]/0: 037cx23885[0]/0: 057cx23885[0]/0: 007cx23885[0]/0: 047cx23885[0]/0: 807cx23885[0]/0: 007cx23885[0]/0: 087cx23885[0]/0: 2c7cx23885[0]/0: 007cx23885[0]/0: 057cx23885[0]/0: 007cx23885[0]/0: 7d7cx23885[0]/0: 107cx23885[0]/0: 817cx23885[0]/0: 667cx23885[0]/0: 0c7cx23885[0]/0: 037cx23885[0]/0: 057cx23885[0]/0: 807cx23885[0]/0: 0e7cx23885[0]/0: 017cx23885[0]/0: 007cx23885[0]/0: 007cx23885[0]/0: 827cx23885[0]/0: 017cx23885[0]/0: 007cx23885[0]/0: 227cx23885[0]/0: 787cx23885[0]/0: 007cx23885[0]/0: 007cx23885[0]/0: 007cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/ Jan 18 01:56:45 htpc1 kernel: 0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0] Jan 18 01:56:45 htpc1 kernel: /0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0: ff7cx23885[0]/0:
[PULL] http://linuxtv.org/hg/~ajacquet/v4l-dvb/
Mauro, Please pull from http://linuxtv.org/hg/~ajacquet/v4l-dvb/ for the following changeset: 01/01: zr364xx: add support for Aiptek DV T300 http://linuxtv.org/hg/~ajacquet/v4l-dvb/?cmd=changeset;node=be8e42c9b9f7 Documentation/video4linux/zr364xx.txt |1 + drivers/media/video/zr364xx.c |1 + 2 files changed, 2 insertions(+) Thanks, Antoine -- Antoine Royale Jacquet http://royale.zerezo.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL -tip] fix 33 make headers_check warnings
Hello Sam, David,
On Sat, 2009-01-17 at 23:19 +0100, Sam Ravnborg wrote:
On Sun, Jan 18, 2009 at 08:37:41AM +1100, David Woodhouse wrote:
On Sun, 2009-01-18 at 01:47 +0530, Jaswinder Singh Rajput wrote:
--- 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 linux/types.h
-#else
+#ifndef __KERNEL__
#include stdint.h
#endif
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.
CHECK include/mtd (6 files)
/home/jaswinder/jaswinder-git/linux-2.6-tip/usr/include/mtd/jffs2-user.h:20:
extern's make no sense in userspace
--
include/mtd/jffs2-user.h:
extern int target_endian;
#define t16(x) ({ uint16_t __b = (x);
(target_endian==__BYTE_ORDER)?__b:bswap_16(__b); })
#define t32(x) ({ uint32_t __b = (x);
(target_endian==__BYTE_ORDER)?__b:bswap_32(__b); })
--
In above case extern is OK or not ?
Do we have some better alternative.
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: [GIT PULL -tip] fix 33 make headers_check warnings
On Sat, 2009-01-17 at 22:33 -0500, Kyle McMartin wrote: On Sun, Jan 18, 2009 at 08:35:01AM +0530, Jaswinder Singh Rajput wrote: Hello Sam, David, /home/jaswinder/jaswinder-git/linux-2.6-tip/usr/include/mtd/jffs2-user.h:20: extern's make no sense in userspace This file is for userspace only, and it makes sense where it's used (mtd-utils.) In general though, this file doesn't actually depend on the kernel and could be entirely provided from the userspace library. If this file is _ONLY_ for userspace and kernel cannot use it then what is the point of keeping this file in kernel headers. -- 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 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? -- 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
