Re: [GIT PATCHES FOR 2.6.38] usbvision BKL removal and cleanup
Hi Hans, Le Wed, 29 Dec 2010 17:56:36 +0100, Hans Verkuil a écrit : > Hi Mauro, > > The first patch converts usbvision to core-assisted locking, the > others do a big coding style cleanup. > > I want to clean up this driver in the future, so the first step is to > fix all the coding style violations first. That way I can actually > read the source code :-) > Good intention. This is something I wanted to do but lack of time. There is a compression algorithm in this driver that should go into userspace. I think this is the hardest part. I can help for the cleanup but cannot lead it right now. Regards, 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] SheevaBox as a media Server and a Fit-PC as a streaming client?
Le Fri, 01 Jan 2010 15:26:54 +0100, DUBOST Brice a écrit : > Markus Rechberger a écrit : > > Hi, > > > > On Wed, Dec 16, 2009 at 4:12 PM, Lothar Behrens > > wrote: > >> Hi, > >> > >> I am new here and start with a setup question. > >> > >> The media or NAS server I think about: http://plugcomputer.org/ > >> > >> It has a high speed USB 2.0 port and a gigabit Lan. > >> > > > > http://support.sundtek.com/index.php/topic,179.0.html (english) > > http://support.sundtek.com/index.php/topic,178.0.html (german) > > > > This might be interesting for you. > > > > Markus > > > > hello > > MuMuDVB is reported to work fine on a sheevaplug > I use my sheevaplug without any problem with a CinergyT2, and I know someone who runs with an empia-based hybrid tuner (Terratec Cinergy hybrid XS) The main bottleneck of the sheevaplug and all ARMv5TE compliant processors is the lack of FPU, if you have to do transcoding stuff (mpeg4->mpeg2 for example) before streaming. To my mind the 'TE' extension should be used for such transcoding but this is off topic. Otherwise, it is perfect to host a streaming server like vlc or MuMuDVB, to stream untouched video frames coming from DVB tuners. 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
[PULL] http://linuxtv.org/hg/~tmerle/v4l-dvb
Hi Mauro, please pull from http://linuxtv.org/hg/~tmerle/v4l-dvb the following patch from Eberhard Mattes: - dvb-usb: fix tuning with Cinergy T2 http://linuxtv.org/hg/~tmerle/v4l-dvb/rev/75be92928287 Eberhard, thanks for this bugfix, I did not have time nor hardware to work on that and you did a great investigation job. cinergyT2-fe.c |1 + 1 file changed, 1 insertion(+) 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] USBVision device defaults
Hi Tim, On Mon, 29 Jun 2009 11:34:50 +0100 (BST) Tim Williams wrote: > > Hello, > > I'm trying use a WinTV USB adaptor which uses the usbvision driver to > capture the output of a video camera for streaming across the web, the > idea being that there is a reliable local recording, even in the event of > a computer crash, while allowing the remote viewers to see the proceedings > live without needing to have two separate cameras. > > Unfortunately there is a catch, i'm using flash to do the broadcast > and flash (in common with a lot of other software of this type) doesn't > have the ability to set the input type and picture format, so you are > stuck with the default, which is the rf-tuner. I have managed to make my > own bodged driver which disables the rf-input so that I can get a picture > via s-video, but it is stubbornly stuck in black and white, which i'm > assuming is some kind of colour format problem. > > If I use KDETV to look at the picture then everything comes through in > colour, so this would seem to be a problem with the defaults built into > the module being incorrect for my circumstances. Rather than carrying on > with my bodged driver (this is the first time I have ever attempted to > modify a C programme), what would be really great is away to achieve one > of the following : > > 1) Set the default input, tv standard and pixel format using module > parameters in modprobe.conf > 2) Get the driver to 'remember' it's current settings when switching > between applications. The windows driver for these devices does this, so > all I have to do under windows is start up WinTV, make sure I have a good > picture, close it down again and then start up the video broadcast in > flash. > 3) A way to change the device settings using a 3rd party app even when the > main video device is in use and can't be accessed. I've tried using v4lctl > to set the parameters before starting a capture, but if the flash capture > is active, then I (unsurprisingly) get device in use errors. If I use v4lctl > before starting flash, then the settings don't stick. The capture box becomes > active briefly (there is a red light on the box which indicates this), > presumably accepts the setting and is then powered down again, causing > the new setting to be immediately forgotten. > > Any thoughts or help would be much appreciated. > I remember a guy that did the trick with the vloopback device. Searching a bit on the Internet, it seems that flashcam http://www.swift-tools.net/Flashcam/ can be convenient for your needs. HTH Regards, 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-usbvision
Hans Verkuil a écrit : > On Thursday 26 February 2009 20:28:06 Mauro Carvalho Chehab wrote: >> On Sat, 21 Feb 2009 22:17:10 +0100 >> >> Hans Verkuil wrote: >>> Hi Mauro, >>> >>> Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-usbvision >>> for the following: >>> >>> - v4l2-common: add v4l2_i2c_subdev_addr() >>> - usbvision: convert to v4l2_device/v4l2_subdev. >> Thierry/Dwaine, >> >> Could you please check if everything is ok with usbvision after those >> patches? > > Just for the record, I did test it on my pinnacle. Sorry, I should have > mentioned it. But it's of course always good to have more testing done. > It is OK; already merged but here is my ack for this patch: Acked-by: Thierry Merle 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: dvb-usb-cinergyT2
Hello Johannes, Johannes Engel wrote: > Hello! > > Switching to the new kernel 2.6.28 including the new driver for my Terratec > Cinergy T² made the thing almost unusable. > Neither mplayer nor scan resp. w_scan is able to tune the card anymore, not > even the led lights up anymore. Sometimes tzap manages to get out a proper > signal, but not reliably. > > The kernel logs says the following: > > dvb-usb: TerraTec/qanu USB2.0 Highspeed DVB-T Receiver successfully > deinitialized and disconnected. > usbcore: deregistering interface driver cinergyT2 > usb 5-1: new high speed USB device using ehci_hcd and address 13 > usb 5-1: config 1 interface 0 altsetting 0 bulk endpoint 0x1 has invalid > maxpacket 64 > usb 5-1: config 1 interface 0 altsetting 0 bulk endpoint 0x81 has invalid > maxpacket 64 > usb 5-1: configuration #1 chosen from 1 choice > usb 5-1: New USB device found, idVendor=0ccd, idProduct=0038 > usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > usb 5-1: Product: Cinergy T� > usb 5-1: Manufacturer: TerraTec GmbH > dvb-usb: found a 'TerraTec/qanu USB2.0 Highspeed DVB-T Receiver' in warm > state. > dvb-usb: will pass the complete MPEG2 transport stream to the software > demuxer. > DVB: registering new adapter (TerraTec/qanu USB2.0 Highspeed DVB-T Receiver) > DVB: registering adapter 0 frontend 0 (TerraTec/qanu USB2.0 Highspeed DVB-T > Receiver)... > input: IR-receiver inside an USB DVB receiver as > /devices/pci:00/:00:1d.7/usb5/5-1/input/input17 > dvb-usb: schedule remote query interval to 50 msecs. > dvb-usb: TerraTec/qanu USB2.0 Highspeed DVB-T Receiver successfully > initialized and connected. > usbcore: registered new interface driver cinergyT2 > > Do you need any further information? Please CC me, since I am not subscribed > to the list. > another user has got the same problem, except that the led still lights up. Can you tell us what it the firmware version in your device? You can see it by doing lsusb -vvv, for the Cinergy T2 entry this is the "bcdDevice" line. I have the 1.06 firmware version and it works. 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: CinergyT2 not working with newer alternative driver
Jason Harvey wrote: > Thierry Merle wrote: >> Another thing, do you know the firmware version of your tuner? >> I have the 1.06 version. >> > Both are running on firmware 1.08 > Wonder if I can downgrade them... will look into that. Yes, and I will try to find time to upgrade mine. >> Look at lsusb -vvv, this is the "bcdDevice" line for the CinergyT2 >> device. >> Sorry but I have no idea of the origin of the problem. >> If I had time I would compare USB dumps between the old driver and the >> new one for the same tuning operation. >> > I'll try and get the USB dumps and a comparison done myself within the > next week or two. OK thanks; I will be able to help you by doing some perl scripts. > Think I have a spare PC around with an older Fedora on it with a kernel > that worked. > I did see another posting to this mail list from someone with the same > problem which I'll take as confirmation that it is not just me :) > Yes I know, but the user did not answer the last time so we committed the redesign and we expect to find another user with the problem :) Regards, 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: CinergyT2 not working with newer alternative driver
Jason Harvey wrote: > Thierry Merle wrote: >> Jason Harvey wrote: >> >>> Thierry Merle wrote: >>> >>>> Hi Jason, >>>> Jason Harvey wrote: >>>> >>>> >>>>> I have been successfully using VDR with two CinergyT2s for 18 months. >>>>> After adding a Hauppage NOVA-S2-HD I updated my v4l-dvb drivers hoping >>>>> to get S2 capability and test a newer VDR for HD reception. >>>>> >>>>> The CinergyT2s stopped working. The kernel module loads, the blue leds >>>>> flash as expected but they don't lock on to a signal for long. >>>>> Signal strength shown in femon is erratic and a lock only rarely >>>>> achieved. >>>>> >>>>> I checked through the mercurial tree to see what had changed. >>>>> It looks like the following change is the one that stops the >>>>> CinergyT2s >>>>> working on my system. >>>>> http://git.kernel.org/?p=linux/kernel/git/mchehab/devel.git;a=commit;h=986bd1e58b18c09b753f797df19251804bfe3e84 >>>>> >>>>> >>>>> >>>>> >>>>> I deleted the newer version of the module and replace it with the >>>>> previous deleted code. >>>>> Make'd and installed the old version works as expected. >>>>> >>>>> Machine they're plugged into is running Fedora 10, >>>>> 2.6.27.12-170.2.5.fc10.i686 >>>>> I downloaded the current v4l-dvb today (31Jan2009) and tried it all >>>>> again before posting this message. >>>>> >>>>> Not sure where to look next, I did start to capture the USB traffic to >>>>> see if I could spot the difference... >>>>> >>>>> >>>> Please take a look at the message logs (dmesg). >>>> You can follow the instructions described here >>>> http://www.linuxtv.org/wiki/index.php/Testing_your_DVB_device >>>> and report where it fails. >>>> >>>> I use tzap like this: tzap -c $HOME/.tzap/channels.conf -s -t 120 -r >>>> -o output.mpg "SomeChannel" >>>> I am able to play with mplayer too. >>>> Regards, >>>> Thierry >>>> >>> Hi Thierry, >>> >>> Thank you for the quick reply. >>> I should have looked in dmesg before... >>> Checking dmesg before I used tzap shows a problem. dvb-usb: recv bulk >>> message failed: -110 >>> >>> Extract of dmesg >>> >>> dvb-usb: found a 'TerraTec/qanu USB2.0 Highspeed DVB-T Receiver' in warm >>> state. >>> dvb-usb: will pass the complete MPEG2 transport stream to the software >>> demuxer. >>> DVB: registering new adapter (TerraTec/qanu USB2.0 Highspeed DVB-T >>> Receiver) >>> DVB: registering adapter 0 frontend 0 (TerraTec/qanu USB2.0 Highspeed >>> DVB-T Receiver)... >>> input: IR-receiver inside an USB DVB receiver as >>> /devices/pci:00/:00:1a.7/usb1/1-1/input/input8 >>> dvb-usb: schedule remote query interval to 50 msecs. >>> dvb-usb: TerraTec/qanu USB2.0 Highspeed DVB-T Receiver successfully >>> initialized and connected. >>> dvb-usb: found a 'TerraTec/qanu USB2.0 Highspeed DVB-T Receiver' in warm >>> state. >>> dvb-usb: will pass the complete MPEG2 transport stream to the software >>> demuxer. >>> DVB: registering new adapter (TerraTec/qanu USB2.0 Highspeed DVB-T >>> Receiver) >>> DVB: registering adapter 1 frontend 0 (TerraTec/qanu USB2.0 Highspeed >>> DVB-T Receiver)... >>> input: IR-receiver inside an USB DVB receiver as >>> /devices/pci:00/:00:1d.7/usb2/2-5/input/input9 >>> dvb-usb: schedule remote query interval to 50 msecs. >>> dvb-usb: TerraTec/qanu USB2.0 Highspeed DVB-T Receiver successfully >>> initialized and connected. >>> usbcore: registered new interface driver cinergyT2 >>> >>> dvb-usb: recv bulk message failed: -110 >>> dvb-usb: recv bulk message failed: -110 >>> >>> >>> >>> Running tzap fails to tune/lock >>> >>> #tzap -a 0 -c channels.conf_dvbt -s -t 120 -r -o output.mpg "BBC ONE" >>> >>> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' >>> reading channels from file 'channels.conf_dvbt' >>> tuning to 5058
Re: CinergyT2 not working with newer alternative driver
Jason Harvey wrote: > Thierry Merle wrote: >> Hi Jason, >> Jason Harvey wrote: >> >>> I have been successfully using VDR with two CinergyT2s for 18 months. >>> After adding a Hauppage NOVA-S2-HD I updated my v4l-dvb drivers hoping >>> to get S2 capability and test a newer VDR for HD reception. >>> >>> The CinergyT2s stopped working. The kernel module loads, the blue leds >>> flash as expected but they don't lock on to a signal for long. >>> Signal strength shown in femon is erratic and a lock only rarely >>> achieved. >>> >>> I checked through the mercurial tree to see what had changed. >>> It looks like the following change is the one that stops the CinergyT2s >>> working on my system. >>> http://git.kernel.org/?p=linux/kernel/git/mchehab/devel.git;a=commit;h=986bd1e58b18c09b753f797df19251804bfe3e84 >>> >>> >>> >>> I deleted the newer version of the module and replace it with the >>> previous deleted code. >>> Make'd and installed the old version works as expected. >>> >>> Machine they're plugged into is running Fedora 10, >>> 2.6.27.12-170.2.5.fc10.i686 >>> I downloaded the current v4l-dvb today (31Jan2009) and tried it all >>> again before posting this message. >>> >>> Not sure where to look next, I did start to capture the USB traffic to >>> see if I could spot the difference... >>> >>> >> Please take a look at the message logs (dmesg). >> You can follow the instructions described here >> http://www.linuxtv.org/wiki/index.php/Testing_your_DVB_device >> and report where it fails. >> >> I use tzap like this: tzap -c $HOME/.tzap/channels.conf -s -t 120 -r >> -o output.mpg "SomeChannel" >> I am able to play with mplayer too. >> Regards, >> Thierry >> > Hi Thierry, > > Thank you for the quick reply. > I should have looked in dmesg before... > Checking dmesg before I used tzap shows a problem. dvb-usb: recv bulk > message failed: -110 > > Extract of dmesg > > dvb-usb: found a 'TerraTec/qanu USB2.0 Highspeed DVB-T Receiver' in warm > state. > dvb-usb: will pass the complete MPEG2 transport stream to the software > demuxer. > DVB: registering new adapter (TerraTec/qanu USB2.0 Highspeed DVB-T > Receiver) > DVB: registering adapter 0 frontend 0 (TerraTec/qanu USB2.0 Highspeed > DVB-T Receiver)... > input: IR-receiver inside an USB DVB receiver as > /devices/pci:00/:00:1a.7/usb1/1-1/input/input8 > dvb-usb: schedule remote query interval to 50 msecs. > dvb-usb: TerraTec/qanu USB2.0 Highspeed DVB-T Receiver successfully > initialized and connected. > dvb-usb: found a 'TerraTec/qanu USB2.0 Highspeed DVB-T Receiver' in warm > state. > dvb-usb: will pass the complete MPEG2 transport stream to the software > demuxer. > DVB: registering new adapter (TerraTec/qanu USB2.0 Highspeed DVB-T > Receiver) > DVB: registering adapter 1 frontend 0 (TerraTec/qanu USB2.0 Highspeed > DVB-T Receiver)... > input: IR-receiver inside an USB DVB receiver as > /devices/pci:00/:00:1d.7/usb2/2-5/input/input9 > dvb-usb: schedule remote query interval to 50 msecs. > dvb-usb: TerraTec/qanu USB2.0 Highspeed DVB-T Receiver successfully > initialized and connected. > usbcore: registered new interface driver cinergyT2 > > dvb-usb: recv bulk message failed: -110 > dvb-usb: recv bulk message failed: -110 > > > > Running tzap fails to tune/lock > > #tzap -a 0 -c channels.conf_dvbt -s -t 120 -r -o output.mpg "BBC ONE" > > using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' > reading channels from file 'channels.conf_dvbt' > tuning to 50580 Hz > video pid 0x0258, audio pid 0x0259 > status 01 | signal c11f | snr | ber | unc | > > No more messages in dmesg. > > I shut down the PC, removed all power, unplugged the CinergyT2s, gave it > twenty seconds and powered back up. > Once it had booted I plugged in one of the devices and the dmesg output > below. > > > usb 2-5: new high speed USB device using ehci_hcd and address 3 > usb 2-5: config 1 interface 0 altsetting 0 bulk endpoint 0x1 has invalid > maxpacket 64 > usb 2-5: config 1 interface 0 altsetting 0 bulk endpoint 0x81 has > invalid maxpacket 64 > usb 2-5: configuration #1 chosen from 1 choice > usb 2-5: New USB device found, idVendor=0ccd, idProduct=0038 > usb 2-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > usb 2-5: Product: Cinergy T? > usb 2-5: Manufacturer:
Re: CinergyT2 not working with newer alternative driver
Hi Jason, Jason Harvey wrote: > I have been successfully using VDR with two CinergyT2s for 18 months. > After adding a Hauppage NOVA-S2-HD I updated my v4l-dvb drivers hoping > to get S2 capability and test a newer VDR for HD reception. > > The CinergyT2s stopped working. The kernel module loads, the blue leds > flash as expected but they don't lock on to a signal for long. > Signal strength shown in femon is erratic and a lock only rarely achieved. > > I checked through the mercurial tree to see what had changed. > It looks like the following change is the one that stops the CinergyT2s > working on my system. > http://git.kernel.org/?p=linux/kernel/git/mchehab/devel.git;a=commit;h=986bd1e58b18c09b753f797df19251804bfe3e84 > > > I deleted the newer version of the module and replace it with the > previous deleted code. > Make'd and installed the old version works as expected. > > Machine they're plugged into is running Fedora 10, > 2.6.27.12-170.2.5.fc10.i686 > I downloaded the current v4l-dvb today (31Jan2009) and tried it all > again before posting this message. > > Not sure where to look next, I did start to capture the USB traffic to > see if I could spot the difference... > Please take a look at the message logs (dmesg). You can follow the instructions described here http://www.linuxtv.org/wiki/index.php/Testing_your_DVB_device and report where it fails. I use tzap like this: tzap -c $HOME/.tzap/channels.conf -s -t 120 -r -o output.mpg "SomeChannel" I am able to play with mplayer too. Regards, 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
[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: [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2
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. Regard, 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
[PATCH 1/5] usbvision: use usb_make_path to report bus info
Hello, Here is the set of patches that makes usb driver use usb_make_path to report bus info (except for pvrusb2 since Mike said he would do the patch) I would like to have a Acked-by for these patches before doing a pull request, to be sure I did not do weird things. Thanks Cheers, Thierry usb_make_path reports canonical bus info. Use it when reporting bus info in VIDIOC_QUERYCAP. Signed-off-by: Thierry MERLE --- diff -r f4d7d0b84940 -r 306881b74bb9 linux/drivers/media/video/usbvision/usbvision-video.c --- a/linux/drivers/media/video/usbvision/usbvision-video.c Sun Jan 18 10:55:38 2009 + +++ b/linux/drivers/media/video/usbvision/usbvision-video.c Tue Jan 20 21:40:44 2009 +0100 @@ -524,8 +524,7 @@ strlcpy(vc->card, usbvision_device_data[usbvision->DevModel].ModelString, sizeof(vc->card)); - strlcpy(vc->bus_info, dev_name(&usbvision->dev->dev), - sizeof(vc->bus_info)); + usb_make_path(usbvision->dev, vc->bus_info, sizeof(vc->bus_info)); vc->version = USBVISION_DRIVER_VERSION; vc->capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_AUDIO | -- 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 5/5] s2255drv: use usb_make_path to report bus info
usb_make_path reports canonical bus info. Use it when reporting bus info in VIDIOC_QUERYCAP. Signed-off-by: Thierry MERLE diff -r 43bb285afc52 -r 6adb3130678d linux/drivers/media/video/s2255drv.c --- a/linux/drivers/media/video/s2255drv.c Tue Jan 20 22:13:45 2009 +0100 +++ b/linux/drivers/media/video/s2255drv.c Tue Jan 20 22:19:25 2009 +0100 @@ -842,8 +842,7 @@ struct s2255_dev *dev = fh->dev; strlcpy(cap->driver, "s2255", sizeof(cap->driver)); strlcpy(cap->card, "s2255", sizeof(cap->card)); - strlcpy(cap->bus_info, dev_name(&dev->udev->dev), - sizeof(cap->bus_info)); + usb_make_path(dev->udev, cap->bus_info, sizeof(cap->bus_info)); cap->version = S2255_VERSION; cap->capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING; return 0; -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] gspca: use usb_make_path to report bus info
usb_make_path reports canonical bus info. Use it when reporting bus info in VIDIOC_QUERYCAP. Signed-off-by: Thierry MERLE diff -r 6ac9dc705aea -r 72ba48adaacd linux/drivers/media/video/gspca/gspca.c --- a/linux/drivers/media/video/gspca/gspca.c Tue Jan 20 22:01:33 2009 +0100 +++ b/linux/drivers/media/video/gspca/gspca.c Tue Jan 20 22:06:58 2009 +0100 @@ -977,8 +977,7 @@ le16_to_cpu(gspca_dev->dev->descriptor.idVendor), le16_to_cpu(gspca_dev->dev->descriptor.idProduct)); } - strncpy(cap->bus_info, gspca_dev->dev->bus->bus_name, - sizeof cap->bus_info); + usb_make_path(gspca_dev->dev, cap->bus_info, sizeof(cap->bus_info)); cap->version = DRIVER_VERSION_NUMBER; cap->capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING -- 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 4/5] uvcvideo: use usb_make_path to report bus info
usb_make_path reports canonical bus info. Use it when reporting bus info in VIDIOC_QUERYCAP. Signed-off-by: Thierry MERLE diff -r 72ba48adaacd -r 43bb285afc52 linux/drivers/media/video/uvc/uvc_v4l2.c --- a/linux/drivers/media/video/uvc/uvc_v4l2.c Tue Jan 20 22:06:58 2009 +0100 +++ b/linux/drivers/media/video/uvc/uvc_v4l2.c Tue Jan 20 22:13:45 2009 +0100 @@ -494,8 +494,7 @@ memset(cap, 0, sizeof *cap); strncpy(cap->driver, "uvcvideo", sizeof cap->driver); strncpy(cap->card, vdev->name, 32); - strncpy(cap->bus_info, video->dev->udev->bus->bus_name, - sizeof cap->bus_info); + usb_make_path(video->dev->udev, cap->bus_info, sizeof(cap->bus_info)); cap->version = DRIVER_VERSION_NUMBER; if (video->streaming->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) cap->capabilities = V4L2_CAP_VIDEO_CAPTURE -- 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 2/5] em28xx: use usb_make_path to report bus info
usb_make_path reports canonical bus info. Use it when reporting bus info in VIDIOC_QUERYCAP. Signed-off-by: Thierry MERLE diff -r 306881b74bb9 -r 6ac9dc705aea linux/drivers/media/video/em28xx/em28xx-video.c --- a/linux/drivers/media/video/em28xx/em28xx-video.c Tue Jan 20 21:40:44 2009 +0100 +++ b/linux/drivers/media/video/em28xx/em28xx-video.c Tue Jan 20 22:01:33 2009 +0100 @@ -1355,7 +1355,7 @@ strlcpy(cap->driver, "em28xx", sizeof(cap->driver)); strlcpy(cap->card, em28xx_boards[dev->model].name, sizeof(cap->card)); - strlcpy(cap->bus_info, dev_name(&dev->udev->dev), sizeof(cap->bus_info)); + usb_make_path(dev->udev, cap->bus_info, sizeof(cap->bus_info)); cap->version = EM28XX_VERSION_CODE; @@ -1543,7 +1543,7 @@ strlcpy(cap->driver, "em28xx", sizeof(cap->driver)); strlcpy(cap->card, em28xx_boards[dev->model].name, sizeof(cap->card)); - strlcpy(cap->bus_info, dev_name(&dev->udev->dev), sizeof(cap->bus_info)); + usb_make_path(dev->udev, cap->bus_info, sizeof(cap->bus_info)); cap->version = EM28XX_VERSION_CODE; cap->capabilities = V4L2_CAP_TUNER; -- 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/~mcisely/pvrusb2
Mauro Carvalho Chehab a écrit : > On Sat, 17 Jan 2009 19:09:51 +0100 > Carsten Meier wrote: > >> Am Fri, 16 Jan 2009 02:47:50 -0200 >> schrieb Mauro Carvalho Chehab : >> >>> For usb devices, usb_make_path() provide a canonical name for the >>> device. For PCI ones, we have pci_name() for the same function. in >>> the case of pci devices, I suspect that all use pci_name(). We just >>> need to use usb_make_path() at the usb ones. >>> >> I looked at the sources for what string gets generated for bus_info by >> usb_make_path(). If it gets used by pvrusb2, my problems are solved, >> because it is constant across standby-wake-up-cycles. The pvrusb2's >> implementation currently delivers "usb 7-2 address 6" here. "address >> 6" corresponds to devnum which gets constantly increased, which results >> in always changing strings here. Sorry for my unneccessary complaints. > > Mike, Thierry, Jean-Francois, Laurent and others: > > IMO, we should patch all usb drivers to use usb_make_path(). It will be more > transparent to userspace, if all drivers provide the bus_info using the same > notation. Comments? > In fact the usbvision code was reporting already a portable information using dev_name. strlcpy(vc->bus_info, dev_name(&usbvision->dev->dev), sizeof(vc->bus_info)); changed to: usb_make_path(usbvision->dev, vc->bus_info, sizeof(vc->bus_info)); shows the same information on my system. It is simpler so I am OK with this change. Do you want us to make separate patch or did you start a global patch? 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: Fw: [PATCH] v4l/dvb: remove err macro from few usb devices
Mauro Carvalho Chehab wrote:
> Alexey,
>
> You should get the driver maintainer's ack or at least let them know that
> you're touching on their drivers.
>
> Mike, Thierry an Dean,
>
> Could you please review this patch?
>
It is OK for usbvision.
Just a note with usbvision-video, Mauro you will have a patch rejection due to
the recent modification on
usb_endpoint_type(endpoint) != USB_ENDPOINT_XFER_ISOC
changed to
!usb_endpoint_xfer_isoc(endpoint)
This does not change anything to the patched lines we talk about here so:
Acked-by: Thierry Merle
> Cheers,
> Mauro.
>
Cheers,
Thierry
> Forwarded message:
>
> Date: Thu, 01 Jan 2009 11:06:08 +0300
> From: Alexey Klimov
> To: Mauro Carvalho Chehab
> Cc: video4linux-l...@redhat.com, Greg KH
> Subject: [PATCH] v4l/dvb: remove err macro from few usb devices
>
>
> Hello all
> I re-send this patch. Previous time i sent i get no response.
> Please nack, apply or criticize :)
>
> --
>
> Patch removes err() macros from few usb devices.
> It places pr_err in pvrusb2-v4l2.c, dev_err in dabusb and in usbvision
> drivers. Beside placing dev_err, patch defines new s2255_dev_err macro
> with S2255_DRIVER_NAME in s2255 module.
>
> Signed-off-by: Alexey Klimov
>
> ---
> diff -r 6a189bc8f115 linux/drivers/media/video/dabusb.c
> --- a/linux/drivers/media/video/dabusb.c Wed Dec 31 15:26:57 2008 -0200
> +++ b/linux/drivers/media/video/dabusb.c Thu Jan 01 10:59:06 2009 +0300
> @@ -199,17 +199,20 @@
> dst += len;
> }
> else
> - err("dabusb_iso_complete: invalid len
> %d", len);
> + dev_err(&purb->dev->dev,
> + "dabusb_iso_complete: invalid
> len %d\n", len);
> }
> else
> dev_warn(&purb->dev->dev, "dabusb_iso_complete:
> corrupted packet status: %d\n", purb->iso_frame_desc[i].status);
> if (dst != purb->actual_length)
> - err("dst!=purb->actual_length:%d!=%d", dst,
> purb->actual_length);
> + dev_err(&purb->dev->dev,
> + "dst!=purb->actual_length:%d!=%d\n",
> + dst, purb->actual_length);
> }
>
> if (atomic_dec_and_test (&s->pending_io) && !s->remove_pending &&
> s->state != _stopped) {
> s->overruns++;
> - err("overrun (%d)", s->overruns);
> + dev_err(&purb->dev->dev, "overrun (%d)\n", s->overruns);
> }
> wake_up (&s->wait);
> }
> @@ -230,13 +233,14 @@
> while (transfer_len < (s->total_buffer_size << 10)) {
> b = kzalloc(sizeof (buff_t), GFP_KERNEL);
> if (!b) {
> - err("kzalloc(sizeof(buff_t))==NULL");
> + dev_err(&s->usbdev->dev,
> + "kzalloc(sizeof(buff_t))==NULL\n");
> goto err;
> }
> b->s = s;
> b->purb = usb_alloc_urb(packets, GFP_KERNEL);
> if (!b->purb) {
> - err("usb_alloc_urb == NULL");
> + dev_err(&s->usbdev->dev, "usb_alloc_urb == NULL\n");
> kfree (b);
> goto err;
> }
> @@ -245,7 +249,8 @@
> if (!b->purb->transfer_buffer) {
> kfree (b->purb);
> kfree (b);
> - err("kmalloc(%d)==NULL", transfer_buffer_length);
> + dev_err(&s->usbdev->dev,
> + "kmalloc(%d)==NULL\n", transfer_buffer_length);
> goto err;
> }
>
> @@ -289,10 +294,11 @@
>
> ret=usb_bulk_msg(s->usbdev, pipe, pb->data, pb->size, &actual_length,
> 100);
> if(ret<0) {
> - err("dabusb: usb_bulk_msg failed(%d)",ret);
> + dev_err(&s->usbdev->dev,
> + "usb_bulk_msg failed(%d)\n", ret);
>
> if (usb_set_interface (s->usbdev, _DABUSB_IF, 1) < 0) {
> - err("set_interface failed");
> + dev_err(
Re: Fw: [PATCH] v4l/dvb: remove err macro from few usb devices
Mike Isely wrote:
> Why is this change needed? (Please point me at a discussion thread, if
> you'd like...)
>
> -Mike
>
I remember this list of patches:
https://kerneltrap.org/mailarchive/linux-usb/2008/10/17/3708324
and
https://kerneltrap.org/mailarchive/linux-usb/2008/10/17/3709124
I think this is related. This is just the extension of these modifications.
Thierry
>
> On Thu, 8 Jan 2009, Mauro Carvalho Chehab wrote:
>
>> Alexey,
>>
>> You should get the driver maintainer's ack or at least let them know that
>> you're touching on their drivers.
>>
>> Mike, Thierry an Dean,
>>
>> Could you please review this patch?
>>
>> Cheers,
>> Mauro.
>>
>> Forwarded message:
>>
>> Date: Thu, 01 Jan 2009 11:06:08 +0300
>> From: Alexey Klimov
>> To: Mauro Carvalho Chehab
>> Cc: video4linux-l...@redhat.com, Greg KH
>> Subject: [PATCH] v4l/dvb: remove err macro from few usb devices
>>
>>
>> Hello all
>> I re-send this patch. Previous time i sent i get no response.
>> Please nack, apply or criticize :)
>>
>> --
>>
>> Patch removes err() macros from few usb devices.
>> It places pr_err in pvrusb2-v4l2.c, dev_err in dabusb and in usbvision
>> drivers. Beside placing dev_err, patch defines new s2255_dev_err macro
>> with S2255_DRIVER_NAME in s2255 module.
>>
>> Signed-off-by: Alexey Klimov
>>
>> ---
>> diff -r 6a189bc8f115 linux/drivers/media/video/dabusb.c
>> --- a/linux/drivers/media/video/dabusb.c Wed Dec 31 15:26:57 2008 -0200
>> +++ b/linux/drivers/media/video/dabusb.c Thu Jan 01 10:59:06 2009 +0300
>> @@ -199,17 +199,20 @@
>> dst += len;
>> }
>> else
>> -err("dabusb_iso_complete: invalid len
>> %d", len);
>> +dev_err(&purb->dev->dev,
>> +"dabusb_iso_complete: invalid
>> len %d\n", len);
>> }
>> else
>> dev_warn(&purb->dev->dev, "dabusb_iso_complete:
>> corrupted packet status: %d\n", purb->iso_frame_desc[i].status);
>> if (dst != purb->actual_length)
>> -err("dst!=purb->actual_length:%d!=%d", dst,
>> purb->actual_length);
>> +dev_err(&purb->dev->dev,
>> +"dst!=purb->actual_length:%d!=%d\n",
>> +dst, purb->actual_length);
>> }
>>
>> if (atomic_dec_and_test (&s->pending_io) && !s->remove_pending &&
>> s->state != _stopped) {
>> s->overruns++;
>> -err("overrun (%d)", s->overruns);
>> +dev_err(&purb->dev->dev, "overrun (%d)\n", s->overruns);
>> }
>> wake_up (&s->wait);
>> }
>> @@ -230,13 +233,14 @@
>> while (transfer_len < (s->total_buffer_size << 10)) {
>> b = kzalloc(sizeof (buff_t), GFP_KERNEL);
>> if (!b) {
>> -err("kzalloc(sizeof(buff_t))==NULL");
>> +dev_err(&s->usbdev->dev,
>> +"kzalloc(sizeof(buff_t))==NULL\n");
>> goto err;
>> }
>> b->s = s;
>> b->purb = usb_alloc_urb(packets, GFP_KERNEL);
>> if (!b->purb) {
>> -err("usb_alloc_urb == NULL");
>> +dev_err(&s->usbdev->dev, "usb_alloc_urb == NULL\n");
>> kfree (b);
>> goto err;
>> }
>> @@ -245,7 +249,8 @@
>> if (!b->purb->transfer_buffer) {
>> kfree (b->purb);
>> kfree (b);
>> -err("kmalloc(%d)==NULL", transfer_buffer_length);
>> +dev_err(&s->usbdev->dev,
>> +"kmalloc(%d)==NULL\n", transfer_buffer_length);
>> goto err;
>> }
>>
>> @@ -289,10 +294,11 @@
>>
>> ret=usb_bulk_msg(s->usbdev, pipe, pb->data, pb->size, &actual_length,
>> 100);
>> if(ret<0) {
>> -err("dabusb: usb_bulk_msg failed(%d)",ret);
>> +dev_err(&s->usbdev->dev,
>> +"usb_bulk_msg failed(%d)\n", ret);
>>
>> if (usb_set_interface (s->usbdev, _DABUSB_IF, 1) < 0) {
>> -err("set_interface failed");
>> +dev_err(&s->usbdev->dev, "set_interface failed\n");
>> return -EINVAL;
>> }
>>
>> @@ -301,7 +307,7 @@
>> if( ret == -EPIPE ) {
>> dev_warn(&s->usbdev->dev, "CLEAR_FEATURE request to remove
>> STALL condition.\n");
>> if(usb_clear_halt(s->usbdev, usb_pipeendpoint(pipe)))
>> -err("request failed");
>> +dev_err(&s->usbdev->dev, "request failed\n");
>> }
>>
>> pb->size = actual_length;
>> @@ -319,7 +325,8 @@
>> unsigned char *transfer_buffer = kmalloc (len, GFP_KERNEL);
>>
>> if (!tra
