Re: adp1653 usage
On Wed, Aug 10, 2011 at 02:16:00PM +0300, Andy Shevchenko wrote: Hello, Sakari. Hi, Andy! I would like to understand how to use subdevice (like adp1653) in current v4l2 framework from user space. My understanding is following. Kernel has two drivers (simplified view): - camera device - flash device Kernel initializes a camera driver from a platform specific setup code. The camera driver loads the subdevice drivers. Later I could access the subdevice driver parts via IOCTL(s) on /dev/videoX device node. What I have missed. - if the subdevice creates device node /dev/v4l-subdevX, how the user space will know the X is corresponding to let say flash device? The whole media device's entities (of which the flash in this case is one of) can be enumerated. The device is called /dev/mediaX. The Media controller API is defined here: URL:http://hverkuil.home.xs4all.nl/spec/media.html#media_common - if there is no v4l-subdevX device node, when and how the kernel runs -open() and -close() methods of v4l2_subdev_internal_ops? No-one. This is part of the user space interface. Isp drivers are also free to use the adp1653 subdev directly, but in embedded systems where such chips typically are used that seldom makes sense. A webcam driver could implement the same interface and provide it through a video node. -- Sakari Ailus sakari.ai...@iki.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: [ANN] Meeting minutes of the Cambourne meeting
On Mon, Aug 08, 2011 at 05:50:06PM +0200, Laurent Pinchart wrote: Hi everybody, Hi, all! The V4L2 brainstorming meeting held in Cambourne from August the 1st to August the 5th was a success. I would like to thank Linaro again, and particularly Stephen Doel and Arwen Donaghey, for accommodating us during the whole week. Here is a summary of the discussions, with preliminary conclusions, ideas, and action points. Thanks for the notes! ... Pixel clock and blanking Preliminary conclusions: - Pixel clock(s) and blanking will be exported through controls on subdev nodes. - The pixel array pixel clock is needed by userspace. - Hosts/bridges/ISPs need pixel clock and blanking information to validate pipelines. I have a small addition to this in my notes: Pixel array and bus configuration for sensors - The CSI-2 bus frequency will receive an integer menu control. Together with the binning, skipping, scaling and CSI-2 output bits-per-pixel information, this allows the sensor driver to calculate the value of the best pixel rate in the sensor, which will be a read-only int64 control. Based on pixel clock, image width, height and ranges on vertical and horizontal blanking, the user can define the frame rate. Vertical and horizontal blanking are implemented as integer controls. Integer menu controls are easy to add; this will be implemented by making the name field in v4l2_querymenu an anonymous union. (I actually have patches for this but haven't tested them yet. I'll send them once I have time for that.) Cheers, -- Sakari Ailus sakari.ai...@iki.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: USB mini-summit at LinuxCon Vancouver
Hi, On 08/11/2011 01:04 AM, Adam Baker wrote: On Tuesday 09 August 2011, Hans de Goede wrote: Hi, On 08/09/2011 10:31 PM, Adam Baker wrote: On Tuesday 09 August 2011, Hans de Goede wrote: snip It has also just occured to me that it might be possible to solve the issues we are facing just in the kernel. At the moment when the kernel performs a USBDEVFS_DISCONNECT it keeps the kernel driver locked out until userspace performs a USBDEVFS_CONNECT. If the kernel reattached the kernel driver when the device file was closed then, as gvfs doesn't keep the file open the biggest current issue would be solved instantly. If a mechanism could be found to prevent USBDEVFS_DISCONNECT from succeeding when the corresponding /dev/videox file was open then that would seem to be a reasonable solution. sigh This has been discussed over and over and over again, playing clever tricks with USBDEVFS_[DIS]CONNECT like adding a new USBDEVFS_TRYDISCONNECT which the v4l2 driver could intercept won't cut it. We need some central manager of the device doing multiplexing between the 2 functions, and you can *not* assume that either side will be nice wrt closing file descriptors. Examples: 1) You are wrong wrt gvfs, it does keep the libgphoto2 context open all the time, and through that the usbfs device nodes. It seems that that depends, on my system gvfs isn't actually automounting the camera after it detects it and the file is only open (according to lsof) when the device is actually mounted. Right, but on some systems it does auto-mount, and even if it does not auto-mount and the user then just clicks on its icon in the filemanager to look at the photo's it will mount, and it will be non obvious to the user to umount it. Once mounted, the /dev/video# node will be gone. So if for example skype gets started it will say the user has no camera. If it were to say the device is busy, the user just might make a link to the mounted gvfs share, but even then that is a big might. The whole disappear / reappear act of the /dev/video# node is one of my concerns with the current solution. As soon as you unmount it the device gets closed again. Because it does do a brief open, USBDEVFS_DISCONNECT then close at connection time it does still disable the kernel driver. Then you've a bug in your libgphoto2, Fedora had a similar bug which I fixed (and send the fix upstream). libgphoto2 now a days does make the call to re-attach the kernel driver. 2) Lets say a user starts a photo managing app like f-spot, and that opens the device through libgphoto2 on startup, then the user switches to another virtual desktop and forgets all about having f-spot open. Notice that if the user now tries to stream he will not get a busy error, but the app trying to do the streaming will simply not see the camera at all (kernel driver unbound /dev/video# node is gone). This does seem like a situation where your approach could potentially give a better user experience. I'm wondering slightly how you define busy though. For webcams the streamon and streamoff ioctls tell you if you are using mmap or userptr transfers but you don't know if when the user has finished if they just use read. For stillcam mode it is again hard to determine a busy condition other than being in the middle of transfering an individual picture. Right, so my plan is to define busy for stillcam mode as not being in the middle of some operation (be it download or delete). 3) Notice that little speaker icon in your panel on your average Linux desktop, that keeps the mixer of the audio device open *all the time* it is quite easy to imagine a similar applet for v4l2 device controls (see for example gtk-v4l) doing the same. Or a user could simply start up a v4l2 control panel app like gtk-v4l, qv4l2 or v4l2ucp, and leave it running minimized ... This again needs a usable concept of busy Actually this one is easy. Most streaming drivers already handle controls while not streaming by remembering the set values, and these cached values usually then get set on stream start. There are multiple reasons for this: - usb transfers are expensive no need to send a value to the device if it may change before it gets actually used - in many cases parts of the device are powered down when not streaming, so sending values while not streaming just drops them in a black hole snip If we come up with a solution that whilst it would be perfect there isn't enough effort available to implement then that is worse than a solution that fixes most of the problem. Agreed. This is an even greater concern when the technically superior solution has a higher long term maintenance overhead (as we no longer get Win32 and OSX users helping to maintain the stillcam drivers). I've been subscribed to the libgphoto2-devel list for quite some time now, I believe I still have to see the first win32 / OS-X user input. We do get occasional FreeBSD input, usually in the form of it no longer
Re: USB mini-summit at LinuxCon Vancouver
Hi, On 08/10/2011 06:09 PM, Alan Stern wrote: On Wed, 10 Aug 2011, Theodore Kilgore wrote: Okay, I didn't realize that the different cameras used different webcam drivers as well as different stillcam drivers. Oh, yes. They are Proprietary devices. And that means what it says. :-) And all different from each other, too. As far as I can see, there's nothing to stop anybody from adding the stillcam functionality into the webcam drivers right now. If some common code can be abstracted out into a shared source file, so much the better. That would solve the problem, right? I think everyone involved believes that it would solve the problem. The question has been all along whether or not there is any other way which would work. Also the question of what, exactly, belongs in the kernel and what does not. For, if something has been historically supported in userspace (stillcam support, in this case) and has worked well there, I would think it is kind of too bad to have to move said support into the kernel just because the same hardware requires kernel support for another functionality and the two sides clash. I mean, the kernel is already big enough, no? But the logic that Hans has set forth seems rather compelling. The alternative seems to be to define a device-sharing protocol for USB drivers. Kernel drivers would implement a new callback (asking them to give up control of the device), and usbfs would implement new ioctls by which a program could ask for and relinquish control of a device. The amount of rewriting needed would be relatively small. A few loose ends would remain, such as how to handle suspends, resumes, resets, and disconnects. Assuming usbfs is the only driver that will want to share a device in this way, we could handle them. Hans, what do you think? First of all thanks for the constructive input! When you say: device-sharing protocol, do you mean 2 drivers been attached, but only 1 being active. Or just some additional glue to make hand-over between them work better? I've 2 concerns with this approach: 1) Assuming we are going for the just make hand over work better solution we will still have the whole disappear / reappear act of the /dev/video# node, which I don't like at all. If for example skype gets started it will say the user has no camera. If it were to say the device is busy, the user just might make a link to some application using the device in stillcam mode still being open. 2) The whole notion of the device being in use is rather vague when it comes to the userspace parts of this. Simply leaving say F-Spot running, or having a gvfs libgphoto share mounted, should not lead to not being able to use the device in webcam mode. But currently it will. Fixing all users of libgphoto2 wrt this is unlikely to happen, and even if we do that now, more broken ones will likely come along later. I estimate 98% of all cameras are not dual mode cameras, so the average stillcam application developer will not test for this. That leaves us with fixing the busy notion inside libgphoto2, iow, release the device as soon as an operation has completed. This will be quite slow, since both drivers don't know anything about each other, they will just know there is some $random_other_driver. So they need to assume the device state is unclean and re-init the device from scratch each time. Where as if we have both functions in one driver, that can remember the actual device state and only make changes if needed, so downloading + deleting 10 photos will lead to setting it to stillcam mode once, rather then 20 times. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
omap3isp buffer alignment
Hi Laurent, If I understood your discussion with Russell [1] correctly, user pointer buffers are required to be page-aligned because of the IOMMU API, and it's desirable to keep the IOMMU driver that way for other subsystems which may use it. So we're stuck with user buffers needing to be page-aligned. There's a check in ispvideo.c:isp_video_buffer_prepare() that the buffer address is 32-byte aligned. Isn't this superfluous considering the page-aligned restriction? -Michael [1] http://www.mail-archive.com/linux-omap%40vger.kernel.org/msg50611.html MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier -- 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: [Workshop-2011] Media Subsystem Workshop 2011
Hi Mauro, On Wed, Aug 03, 2011 at 02:21:05PM -0300, Mauro Carvalho Chehab wrote: As already announced, we're continuing the planning for this year's media subsystem workshop. To avoid overriding the main ML with workshop-specifics, a new ML was created: workshop-2...@linuxtv.org I'll also be updating the event page at: http://www.linuxtv.org/events.php Over the one-year period, we had 242 developers contributing to the subsystem. Thank you all for that! Unfortunately, the space there is limited, and we can't affort to have all developers there. Due to that some criteria needed to be applied to create a short list of people that were invited today to participate. The main criteria were to select the developers that did significant contributions for the media subsystem over the last 1 year period, measured in terms of number of commits and changed lines to the kernel drivers/media tree. As the used criteria were the number of kernel patches, userspace-only developers weren't included on the invitations. It would be great to have there open source application developers as well, in order to allow us to tune what's needed from applications point of view. So, if you're leading the development of some V4L and/or DVB open-source application and wants to be there, or you think you can give good contributions for helping to improve the subsystem, please feel free to send us an email. With regards to the themes, we're received, up to now, the following proposals: -+-- THEME| Proposed-by: -+-- Buffer management: snapshot mode | Guennadi Rotation in webcams in tablets while streaming is active | Hans de Goede V4L2 Spec ??? ambiguities fix | Hans Verkuil V4L2 compliance test results | Hans Verkuil Media Controller presentation (probably for Wed, 25) | Laurent Pinchart Workshop summary presentation on Wed, 25 | Mauro Carvalho Chehab -+-- From my side, I also have the following proposals: 1) DVB API consistency - what to do with the audio and video DVB API's that conflict with V4L2 and (somewhat) with ALSA? 2) Multi FE support - How should we handle a frontend with multiple delivery systems like DRX-K frontend? 3) videobuf2 - migration plans for legacy drivers 4) NEC IR decoding - how should we handle 32, 24, and 16 bit protocol variations? Even if you won't be there, please feel free to propose themes for discussion, in order to help us to improve even more the subsystem. Drawing from our recent discussions over e-mail, I would like to add another topic: the V4L2 on desktop vs. embedded systems. The V4L2 is being used as an application interface on desktop systems, but recently as support has been added to complex camera ISPs in embedded systems it is used for a different purpose: it's a much lower level interface for specialised user space which typically contains a middleware layer which provides its own application interface (e.g. GSTphotography). The V4L2 API in the two different kind of systems is exactly the same but its role is different: the hardware drivers are not up to offering an interface suitable for the use by general purpose applications. To run generic purpose applications on such embedded systems, I have promoted the use of libv4l (either plain or with plugins) to provide what is missing from between the V4L2, Media controller and v4l2_subdev interfaces provided by kernel drivers --- which mostly allow controlling the hardware --- and what the general purpose applications need. Much of the missing functionality is usually implemented in algorithm frameworks and libraries that do not fit to kernel space: they are complex and often the algorithms themselves are under very restrictive licenses. There is an upside: the libv4l does contain an automatic exposure and a white balance algorithm which are suitable for some use cases. Defining functionality suitable for general purpose applications at the level of V4L2 requires scores of policy decisions on embedded systems. One of the examples is the pipeline configuration for which the Media controller and v4l2_subdev interfaces are currently being used for. Applications such as Fcam URL:http://fcam.garage.maemo.org/ do need to make these policy decisions by themselves. For this reason, I consider it highly important that the low level hardware control interface is available to the user space applications. I think it is essential for the future support of such embedded devices in the mainline kernel to come to a common agreement on how this kind of systems should be
Re: [Workshop-2011] Media Subsystem Workshop 2011
Em 11-08-2011 07:16, Sakari Ailus escreveu: Hi Mauro, On Wed, Aug 03, 2011 at 02:21:05PM -0300, Mauro Carvalho Chehab wrote: As already announced, we're continuing the planning for this year's media subsystem workshop. To avoid overriding the main ML with workshop-specifics, a new ML was created: workshop-2...@linuxtv.org I'll also be updating the event page at: http://www.linuxtv.org/events.php Over the one-year period, we had 242 developers contributing to the subsystem. Thank you all for that! Unfortunately, the space there is limited, and we can't affort to have all developers there. Due to that some criteria needed to be applied to create a short list of people that were invited today to participate. The main criteria were to select the developers that did significant contributions for the media subsystem over the last 1 year period, measured in terms of number of commits and changed lines to the kernel drivers/media tree. As the used criteria were the number of kernel patches, userspace-only developers weren't included on the invitations. It would be great to have there open source application developers as well, in order to allow us to tune what's needed from applications point of view. So, if you're leading the development of some V4L and/or DVB open-source application and wants to be there, or you think you can give good contributions for helping to improve the subsystem, please feel free to send us an email. With regards to the themes, we're received, up to now, the following proposals: -+-- THEME| Proposed-by: -+-- Buffer management: snapshot mode | Guennadi Rotation in webcams in tablets while streaming is active | Hans de Goede V4L2 Spec ??? ambiguities fix | Hans Verkuil V4L2 compliance test results | Hans Verkuil Media Controller presentation (probably for Wed, 25) | Laurent Pinchart Workshop summary presentation on Wed, 25 | Mauro Carvalho Chehab -+-- From my side, I also have the following proposals: 1) DVB API consistency - what to do with the audio and video DVB API's that conflict with V4L2 and (somewhat) with ALSA? 2) Multi FE support - How should we handle a frontend with multiple delivery systems like DRX-K frontend? 3) videobuf2 - migration plans for legacy drivers 4) NEC IR decoding - how should we handle 32, 24, and 16 bit protocol variations? Even if you won't be there, please feel free to propose themes for discussion, in order to help us to improve even more the subsystem. Drawing from our recent discussions over e-mail, I would like to add another topic: the V4L2 on desktop vs. embedded systems. Topic added to: http://www.linuxtv.org/events.php The V4L2 is being used as an application interface on desktop systems, but recently as support has been added to complex camera ISPs in embedded systems it is used for a different purpose: it's a much lower level interface for specialised user space which typically contains a middleware layer which provides its own application interface (e.g. GSTphotography). The V4L2 API in the two different kind of systems is exactly the same but its role is different: the hardware drivers are not up to offering an interface suitable for the use by general purpose applications. To run generic purpose applications on such embedded systems, I have promoted the use of libv4l (either plain or with plugins) to provide what is missing from between the V4L2, Media controller and v4l2_subdev interfaces provided by kernel drivers --- which mostly allow controlling the hardware --- and what the general purpose applications need. Much of the missing functionality is usually implemented in algorithm frameworks and libraries that do not fit to kernel space: they are complex and often the algorithms themselves are under very restrictive licenses. There is an upside: the libv4l does contain an automatic exposure and a white balance algorithm which are suitable for some use cases. Defining functionality suitable for general purpose applications at the level of V4L2 requires scores of policy decisions on embedded systems. One of the examples is the pipeline configuration for which the Media controller and v4l2_subdev interfaces are currently being used for. Applications such as Fcam URL:http://fcam.garage.maemo.org/ do need to make these policy decisions by themselves. For this reason, I consider it highly important that the low level hardware control interface is available to the user space applications. I think it is essential for the future support of
Re: [PATCH 1/6 v4] V4L: add two new ioctl()s for multi-size videobuffer management
On Wed, Aug 10, 2011 at 08:25:24AM +0200, Hans Verkuil wrote: On Wednesday, August 10, 2011 01:37:27 Sakari Ailus wrote: On Tue, Aug 09, 2011 at 09:26:30AM +0200, Hans Verkuil wrote: ... Wouldn't that be a security issue ? Any application with permissions to access the video device could DoS the system. How is this any different from an application that tries to use more memory then there is available? It's an out-of-memory situation, that can happen at any time. Anyone can make an application that runs out of memory. Out-of-memory is not a security risk AFAIK. If you coun availability to security, then it is. This might not be an issue in embedded systems which have a single user, but think of the availability of the interface in e.g. a server. Also, this memory is locked to system physical memory, making it impossible to page it out to a block device. So? Anyone can make a program that allocates and uses a lot of memory causing an out of memory error. I still don't see how that differs from trying to allocate these buffers. The difference is between physical and virtual memory. Reserving buffers pinned in physical memory will starve all the other users very efficiently. Out of memory is a normal condition, not a security risk. Administrators of largish servers with thousands of users might disagree. I have to admit I don't know their usage patterns very well so I have no demands on the issue. ulimit is being used in those systems as is quota, that I know. On the other hand, those systems typically do not contain V4L2 devices either. The problem I have is that you can't really determine a valid policy here since that will depend entirely on your use-case and (embedded) device. This is quite similar case as with the CMA in my opinion. The proposal (by Arnd, if my memory serves me correctly) was to limit the CMA allocations under certain percentage of the system memory address space. The limit could be overriddend e.g. in board code. -- Sakari Ailus sakari.ai...@iki.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
Problems with Tevii S660
Hello list, I just bought a Tevii S660 DVB-S2 USb tunner and I have some problems with it. I already has the Tevii S470 card and it works great with this configuration: mkdir /usr/local/src/dvb cd /usr/local/src/dvb wget http://tevii.com/100315_Beta_linux_tevii_ds3000.rar unrar x 100315_Beta_linux_tevii_ds3000.rar cp *.fw /lib/firmware tar xjvf linux-tevii-ds3000.tar.bz2 cd linux-tevii-ds3000 make make install I am using Debian Squeeze with stable kernel: 2.6.32-5-686 I configured the modprobe this way: # cat /etc/modprobe.d/options.conf #Tevii S470 options cx23885 adapter_nr=7 #Tevii S660 options dvb-usb-dw2102 adapter_nr=6 #Disable the IR options dvb-usb disable_rc_polling=1 At first time it works well, I just pluged it and it creates a dvb device on /dev/dvb/adapter6 and the dmesg is correct (I have not a copy of the message). I didn't try yet to watch any channel (I am uusing MythTV). I reboot the machine and there are some USB error on the boot secuence, something like this: ... device descriptor read/64, error -110 (Here is a photo of the screen: http://i53.tinypic.com/2u3z5s0.jpg) After a long boot, I execute the dmesg and this is what I get: [ 145.909045] usb 4-2: device descriptor read/64, error -110 [ 146.189073] usb 4-2: new full speed USB device using ohci_hcd and address 5 [ 151.208761] usb 4-2: device descriptor read/8, error -110 [ 156.329684] usb 4-2: device descriptor read/8, error -110 [ 156.612043] usb 4-2: new full speed USB device using ohci_hcd and address 6 [ 161.636610] usb 4-2: device descriptor read/8, error -110 [ 166.756544] usb 4-2: device descriptor read/8, error -110 [ 166.864081] hub 4-0:1.0: unable to enumerate USB device on port 2 And there is no device on lsusb. Then I try to boot without the device, it start well the machine, then plug the device and this is the dmesg: [ 162.372030] usb 1-2: new high speed USB device using ehci_hcd and address 2 [ 177.484038] usb 1-2: device descriptor read/64, error -110 [ 192.700039] usb 1-2: device descriptor read/64, error -110 [ 192.920036] usb 1-2: new high speed USB device using ehci_hcd and address 3 [ 208.028034] usb 1-2: device descriptor read/64, error -110 [ 223.252028] usb 1-2: device descriptor read/64, error -110 [ 223.465028] usb 1-2: new high speed USB device using ehci_hcd and address 4 [ 228.484176] usb 1-2: device descriptor read/8, error -110 [ 233.604097] usb 1-2: device descriptor read/8, error -110 [ 233.820029] usb 1-2: new high speed USB device using ehci_hcd and address 5 [ 238.840170] usb 1-2: device descriptor read/8, error -110 [ 243.961092] usb 1-2: device descriptor read/8, error -110 [ 244.064050] hub 1-0:1.0: unable to enumerate USB device on port 2 [ 244.392034] usb 3-2: new full speed USB device using ohci_hcd and address 2 [ 259.568033] usb 3-2: device descriptor read/64, error -110 [ 274.848036] usb 3-2: device descriptor read/64, error -110 [ 275.128035] usb 3-2: new full speed USB device using ohci_hcd and address 3 I contact with Tevii, but there is no support for this device on Linux, they point me to go to http://mercurial.intuxication.org/hg/s2-liplianin/ I read some users having same problem with this device, here is one that resolve it uploading I new firmware on each boot: http://www.gilzad.de/blog/pivot/entry.php?id=7 Can you help with this? I am not an expert on kernel/driver/firmware, I will apreciate any help. Thanks for your help and best regards. -- Josu Lazkano -- 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: adp1653 usage
On Thu, 2011-08-11 at 10:19 +0300, Sakari Ailus wrote: - if the subdevice creates device node /dev/v4l-subdevX, how the user space will know the X is corresponding to let say flash device? The whole media device's entities (of which the flash in this case is one of) can be enumerated. The device is called /dev/mediaX. The Media controller API is defined here: URL:http://hverkuil.home.xs4all.nl/spec/media.html#media_common Thanks for the link and explanations. I just noticed the adp1653 driver has not defined the type of the media entity. I have attached a patch just in case. -- Andy Shevchenko andriy.shevche...@linux.intel.com Intel Finland Oy -- 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] adp1653: set media entity type
The type of a media entity is default for this driver. This patch makes it explicitly defined as MEDIA_ENT_T_V4L2_SUBDEV_FLASH. Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com --- drivers/media/video/adp1653.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/adp1653.c b/drivers/media/video/adp1653.c index 7f2e710..0fd9579 100644 --- a/drivers/media/video/adp1653.c +++ b/drivers/media/video/adp1653.c @@ -438,6 +438,8 @@ static int adp1653_probe(struct i2c_client *client, if (ret 0) goto free_and_quit; + flash-subdev.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_FLASH; + return 0; free_and_quit: -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] [media] OMAP_VOUT: Fix build break caused by update_mode removal in DSS2
-Original Message-
From: Taneja, Archit
Sent: Friday, August 05, 2011 12:49 PM
To: Hiremath, Vaibhav; linux-media@vger.kernel.org
Cc: k...@dominion.thruhere.net; Valkeinen, Tomi; linux-
o...@vger.kernel.org; Taneja, Archit
Subject: [PATCH] [media] OMAP_VOUT: Fix build break caused by update_mode
removal in DSS2
The DSS2 driver does not support the configuration of the update_mode of a
panel anymore. Remove the setting of update_mode done in omap_vout_probe().
Ignore configuration of TE since omap_vout driver doesn't support manual
update
displays anyway.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/video/omap/omap_vout.c | 13 -
1 files changed, 0 insertions(+), 13 deletions(-)
[Hiremath, Vaibhav]
Acked-by: Vaibhav Hiremath hvaib...@ti.com
Tested-by: Vaibhav Hiremath hvaib...@ti.com
Since this is bug fix (results in build failure), I will queue up for next rc.
Thanks,
Vaibhav
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index b5ef362..b3a5ecd 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -2194,19 +2194,6 @@ static int __init omap_vout_probe(struct
platform_device *pdev)
'%s' Display already enabled\n,
def_display-name);
}
- /* set the update mode */
- if (def_display-caps
- OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE) {
- if (dssdrv-enable_te)
- dssdrv-enable_te(def_display, 0);
- if (dssdrv-set_update_mode)
- dssdrv-set_update_mode(def_display,
- OMAP_DSS_UPDATE_MANUAL);
- } else {
- if (dssdrv-set_update_mode)
- dssdrv-set_update_mode(def_display,
- OMAP_DSS_UPDATE_AUTO);
- }
}
}
--
1.7.1
--
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
saa7146 interrupt problems with threadirqs in kernel command line
Hi there, if I define threadirqs in kernel command line my PCI-DVB-C card constantly logs interrupt problems in dmesg like this: saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer DVB: TDA10021(0): _tda10021_writereg, writereg error (reg == 0x03, val == 0x0a, ret == -5) DVB: TDA10021: tda10021_readreg: readreg error (ret == -5) tda10021: lock tuner fails saa7146 (0) vpeirq: used 1 times 80% of buffer (1281972 bytes now) The effect is a not working DVB-stream. :-/ I've already increased the buffer size of the budged_core module: cat /etc/modprobe.d/budget_core.conf options budget_core bufsize=1410 dmesg on initializing the DVB-card: budget_av :05:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 saa7146: found saa7146 @ mem f8b0 (revision 1, irq 16) (0x153b,0x1156). saa7146 (0): dma buffer size 1347584 DVB: registering new adapter (Terratec Cinergy 1200 DVB-C) adapter failed MAC signature check encoded MAC from EEPROM was ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff KNC1-0: MAC addr = 00:0a:ac:01:da:a5 TDA10021: i2c-addr = 0x0c, id = 0x7c DVB: registering adapter 0 frontend 0 (Philips TDA10021 DVB-C)... budget-av: ci interface initialised. As soon as I remove the threadirqs statement from kernel command line the card works well. Is the driver not yet ready for threadirqs? I am running latest stable linux kernel 3.0.1. Thanks for any hints. Alois -- 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: Problems with Tevii S660
2011/8/11 Josu Lazkano josu.lazk...@gmail.com: Hello list, I just bought a Tevii S660 DVB-S2 USb tunner and I have some problems with it. I already has the Tevii S470 card and it works great with this configuration: mkdir /usr/local/src/dvb cd /usr/local/src/dvb wget http://tevii.com/100315_Beta_linux_tevii_ds3000.rar unrar x 100315_Beta_linux_tevii_ds3000.rar cp *.fw /lib/firmware tar xjvf linux-tevii-ds3000.tar.bz2 cd linux-tevii-ds3000 make make install I am using Debian Squeeze with stable kernel: 2.6.32-5-686 I configured the modprobe this way: # cat /etc/modprobe.d/options.conf #Tevii S470 options cx23885 adapter_nr=7 #Tevii S660 options dvb-usb-dw2102 adapter_nr=6 #Disable the IR options dvb-usb disable_rc_polling=1 At first time it works well, I just pluged it and it creates a dvb device on /dev/dvb/adapter6 and the dmesg is correct (I have not a copy of the message). I didn't try yet to watch any channel (I am uusing MythTV). I reboot the machine and there are some USB error on the boot secuence, something like this: ... device descriptor read/64, error -110 (Here is a photo of the screen: http://i53.tinypic.com/2u3z5s0.jpg) After a long boot, I execute the dmesg and this is what I get: [ 145.909045] usb 4-2: device descriptor read/64, error -110 [ 146.189073] usb 4-2: new full speed USB device using ohci_hcd and address 5 [ 151.208761] usb 4-2: device descriptor read/8, error -110 [ 156.329684] usb 4-2: device descriptor read/8, error -110 [ 156.612043] usb 4-2: new full speed USB device using ohci_hcd and address 6 [ 161.636610] usb 4-2: device descriptor read/8, error -110 [ 166.756544] usb 4-2: device descriptor read/8, error -110 [ 166.864081] hub 4-0:1.0: unable to enumerate USB device on port 2 And there is no device on lsusb. Then I try to boot without the device, it start well the machine, then plug the device and this is the dmesg: [ 162.372030] usb 1-2: new high speed USB device using ehci_hcd and address 2 [ 177.484038] usb 1-2: device descriptor read/64, error -110 [ 192.700039] usb 1-2: device descriptor read/64, error -110 [ 192.920036] usb 1-2: new high speed USB device using ehci_hcd and address 3 [ 208.028034] usb 1-2: device descriptor read/64, error -110 [ 223.252028] usb 1-2: device descriptor read/64, error -110 [ 223.465028] usb 1-2: new high speed USB device using ehci_hcd and address 4 [ 228.484176] usb 1-2: device descriptor read/8, error -110 [ 233.604097] usb 1-2: device descriptor read/8, error -110 [ 233.820029] usb 1-2: new high speed USB device using ehci_hcd and address 5 [ 238.840170] usb 1-2: device descriptor read/8, error -110 [ 243.961092] usb 1-2: device descriptor read/8, error -110 [ 244.064050] hub 1-0:1.0: unable to enumerate USB device on port 2 [ 244.392034] usb 3-2: new full speed USB device using ohci_hcd and address 2 [ 259.568033] usb 3-2: device descriptor read/64, error -110 [ 274.848036] usb 3-2: device descriptor read/64, error -110 [ 275.128035] usb 3-2: new full speed USB device using ohci_hcd and address 3 I contact with Tevii, but there is no support for this device on Linux, they point me to go to http://mercurial.intuxication.org/hg/s2-liplianin/ I read some users having same problem with this device, here is one that resolve it uploading I new firmware on each boot: http://www.gilzad.de/blog/pivot/entry.php?id=7 Can you help with this? I am not an expert on kernel/driver/firmware, I will apreciate any help. Thanks for your help and best regards. -- Josu Lazkano Hello again, I try it on the work again, I just install the driver and set the modprobe. I attached and all looks well: $ dmesg [ 5424.064262] usb 1-3: new high speed USB device using ehci_hcd and address 4 [ 5424.196383] usb 1-3: New USB device found, idVendor=9022, idProduct=d660 [ 5424.196387] usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 5424.196481] usb 1-3: configuration #1 chosen from 1 choice [ 5424.433400] dvb-usb: found a 'TeVii S660 USB' in cold state, will try to load a firmware [ 5424.433403] usb 1-3: firmware: requesting dvb-usb-teviis660.fw [ 5424.548027] dvb-usb: downloading firmware from file 'dvb-usb-teviis660.fw' [ 5424.548030] dw2102: start downloading DW210X firmware [ 5424.564904] usb 1-3: USB disconnect, address 4 [ 5424.668011] dvb-usb: found a 'TeVii S660 USB' in warm state. [ 5424.668045] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 5424.668062] DVB: registering new adapter (TeVii S660 USB) [ 5428.764009] dvb-usb: MAC address: d3:d3:d3:d3:d3:d3 [ 5428.828255] Only Zarlink VP310/MT312/ZL10313 are supported chips. [ 5429.084260] Invalid probe, probably not a DS3000 [ 5429.084322] dvb-usb: no frontend was attached by 'TeVii S660 USB' [ 5429.084325] dvb-usb: TeVii S660 USB successfully initialized and connected. [ 5429.084353] usbcore: registered new interface driver dw2102 [
Re: USB mini-summit at LinuxCon Vancouver
On Thu, 11 Aug 2011, Hans de Goede wrote: The alternative seems to be to define a device-sharing protocol for USB drivers. Kernel drivers would implement a new callback (asking them to give up control of the device), and usbfs would implement new ioctls by which a program could ask for and relinquish control of a device. The amount of rewriting needed would be relatively small. A few loose ends would remain, such as how to handle suspends, resumes, resets, and disconnects. Assuming usbfs is the only driver that will want to share a device in this way, we could handle them. Hans, what do you think? First of all thanks for the constructive input! When you say: device-sharing protocol, do you mean 2 drivers been attached, but only 1 being active. Or just some additional glue to make hand-over between them work better? I was thinking that the webcam driver would always be attached, but from time to time usbfs would ask to use the device. When the webcam driver gives away control, it remains bound to the device but does not send any URBs. If it needs to send an URB, first it has to ask usbfs to give control back. I've 2 concerns with this approach: 1) Assuming we are going for the just make hand over work better solution we will still have the whole disappear / reappear act of the /dev/video# node, which I don't like at all. That will not happen any more, because the webcam driver will always be bound to the device. If for example skype gets started it will say the user has no camera. If it were to say the device is busy, the user just might make a link to some application using the device in stillcam mode still being open. 2) The whole notion of the device being in use is rather vague when it comes to the userspace parts of this. Simply leaving say F-Spot running, or having a gvfs libgphoto share mounted, should not lead to not being able to use the device in webcam mode. But currently it will. That's true -- but it's true no matter what solution we adopt. The various drivers (whether in the kernel or in userspace) will have to decide for themselves when they can give up control. Fixing all users of libgphoto2 wrt this is unlikely to happen, and even if we do that now, more broken ones will likely come along later. I estimate 98% of all cameras are not dual mode cameras, so the average stillcam application developer will not test for this. Not all users of libgphoto2 have to be changed; only those which manage dual-mode cameras. Adding a few ioctls to ask for and give up control at the appropriate times must be a lot easier than porting the entire driver into the kernel. That leaves us with fixing the busy notion inside libgphoto2, iow, release the device as soon as an operation has completed. This will be quite slow, since both drivers don't know anything about each other, they will just know there is some $random_other_driver. So they need to assume the device state is unclean and re-init the device from scratch each time. Well, a user program can assume that the kernel driver left the device in a clean state. The reverse isn't always true, however -- it's one of the drawbacks of using a userspace driver. Besides, even though drivers don't always have to re-init the device from scratch every time, they do send all the current settings each time they use the device. So maybe the extra overhead is tolerable. Where as if we have both functions in one driver, that can remember the actual device state and only make changes if needed, so downloading + deleting 10 photos will lead to setting it to stillcam mode once, rather then 20 times. Depends how the ask-for-control ioctl is implemented. It might return a value indicating whether or not the webcam driver took control during the interval when the user program wasn't using the device. If usbfs retained control the entire time, the program should be able to assume the device's state hasn't changed. I'm not claiming that this is a better solution than putting everything in the kernel. Just that it is a workable alternative which would involve a lot less coding. Alan Stern -- 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: USB mini-summit at LinuxCon Vancouver
Em 11-08-2011 11:56, Alan Stern escreveu: On Thu, 11 Aug 2011, Hans de Goede wrote: The alternative seems to be to define a device-sharing protocol for USB drivers. Kernel drivers would implement a new callback (asking them to give up control of the device), and usbfs would implement new ioctls by which a program could ask for and relinquish control of a device. The amount of rewriting needed would be relatively small. A few loose ends would remain, such as how to handle suspends, resumes, resets, and disconnects. Assuming usbfs is the only driver that will want to share a device in this way, we could handle them. Hans, what do you think? First of all thanks for the constructive input! When you say: device-sharing protocol, do you mean 2 drivers been attached, but only 1 being active. Or just some additional glue to make hand-over between them work better? I was thinking that the webcam driver would always be attached, but from time to time usbfs would ask to use the device. When the webcam driver gives away control, it remains bound to the device but does not send any URBs. If it needs to send an URB, first it has to ask usbfs to give control back. I've 2 concerns with this approach: 1) Assuming we are going for the just make hand over work better solution we will still have the whole disappear / reappear act of the /dev/video# node, which I don't like at all. That will not happen any more, because the webcam driver will always be bound to the device. If for example skype gets started it will say the user has no camera. If it were to say the device is busy, the user just might make a link to some application using the device in stillcam mode still being open. 2) The whole notion of the device being in use is rather vague when it comes to the userspace parts of this. Simply leaving say F-Spot running, or having a gvfs libgphoto share mounted, should not lead to not being able to use the device in webcam mode. But currently it will. That's true -- but it's true no matter what solution we adopt. The various drivers (whether in the kernel or in userspace) will have to decide for themselves when they can give up control. Between two or more kernel drivers, a resource locking mechanism like the one you've proposed works fine, but, when the driver is on userspace, there's one additional issue that needs to be addressed: What happens if, for example, if a camera application using libgphoto2 crashes? The lock will be enabled, and the V4L driver will be locked forever. Also, if the lock is made generic enough to protect between two different userspace applications, re-starting the camera application won't get the control back. To avoid such risk, kernel might need to implement some ugly hacks to detect when the application was killed, and put the device into a sane state, if this happens. Fixing all users of libgphoto2 wrt this is unlikely to happen, and even if we do that now, more broken ones will likely come along later. I estimate 98% of all cameras are not dual mode cameras, so the average stillcam application developer will not test for this. Not all users of libgphoto2 have to be changed; only those which manage dual-mode cameras. Adding a few ioctls to ask for and give up control at the appropriate times must be a lot easier than porting the entire driver into the kernel. Again, applications that won't implement this control will take the lock forever. That leaves us with fixing the busy notion inside libgphoto2, iow, release the device as soon as an operation has completed. This will be quite slow, since both drivers don't know anything about each other, they will just know there is some $random_other_driver. So they need to assume the device state is unclean and re-init the device from scratch each time. Well, a user program can assume that the kernel driver left the device in a clean state. The reverse isn't always true, however -- it's one of the drawbacks of using a userspace driver. Besides, even though drivers don't always have to re-init the device from scratch every time, they do send all the current settings each time they use the device. So maybe the extra overhead is tolerable. Where as if we have both functions in one driver, that can remember the actual device state and only make changes if needed, so downloading + deleting 10 photos will lead to setting it to stillcam mode once, rather then 20 times. Depends how the ask-for-control ioctl is implemented. It might return a value indicating whether or not the webcam driver took control during the interval when the user program wasn't using the device. If usbfs retained control the entire time, the program should be able to assume the device's state hasn't changed. I'm not claiming that this is a better solution than putting everything in the kernel. Just that it is a workable alternative which would involve a lot less coding.
Re: USB mini-summit at LinuxCon Vancouver
Between two or more kernel drivers, a resource locking mechanism like the one you've proposed works fine, but, when the driver is on userspace, there's one additional issue that needs to be addressed: What happens if, for example, if a camera application using libgphoto2 crashes? The lock will be enabled, and the V4L driver will be locked forever. Also, if the lock is made generic enough to protect between two different userspace applications, re-starting the camera application won't get the control back. Actually there are more issues than that - you've also got to worry about a security/permission model, and that is hard to get right, especially if you are not very careful that anything that can be retrieved which might violate the security model (eg the last frame on the capture) has been blanked before handover etc. To avoid such risk, kernel might need to implement some ugly hacks to detect when the application was killed, and put the device into a sane state, if this happens. At which point history says it's easier to do the job right, once, in the kernel. Again, applications that won't implement this control will take the lock forever. And applications that are touching both video (even indirectly) and still camera may get surprise deadlocks if they accidentally reference both the still and video device even via some library or service. Well, a user program can assume that the kernel driver left the device in a clean state. The reverse isn't always true, however -- it's one Not it cannot - the user program doesn't know a) if the kernel driver has ever been loaded b) the values the kernel driver leaves set (and those will change no doubt at times) c) if the camera has been plugged and unplugged and not yet had the kernel driver loaded To me it sounds like a recipe for disaster. For those tiny number of devices involved just use V4L and if need be some small V4L tweaks to handle still mode. In most cases the interface is basically identical and I'd bet much of the code is identical too. Alan -- 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: USB mini-summit at LinuxCon Vancouver
Alan Cox raised a bunch of good points. I'm not going to respond to them; they pretty much speak for themselves. On Thu, 11 Aug 2011, Mauro Carvalho Chehab wrote: Between two or more kernel drivers, a resource locking mechanism like the one you've proposed works fine, It's not a locking mechanism. More like cooperative multi-access. but, when the driver is on userspace, there's one additional issue that needs to be addressed: What happens if, for example, if a camera application using libgphoto2 crashes? The lock will be enabled, and the V4L driver will be locked forever. Also, if the lock is made generic enough to protect between two different userspace applications, re-starting the camera application won't get the control back. You're wrong, because what I proposed isn't a lock. If the user program dies, the usbfs device file will automatically be closed and then usbfs will freely give control back to the webcam driver. If the program hangs at the wrong time, then the webcam driver won't be able to regain control. At least the user will have the option of killing the program when this happens; a similar hang in a kernel driver tends to be much uglier. Two different user programs trying to drive the device at the same time doesn't necessarily have to cause a problem. At any particular moment, only one of them would be in control of the device. To avoid such risk, kernel might need to implement some ugly hacks to detect when the application was killed, and put the device into a sane state, if this happens. No ugly hack is needed. usbfs can directly inform the webcam driver whether or not the device file was closed while the user program retained control. If that didn't happen, it's safe to assume that the program gave up control voluntarily. Not all users of libgphoto2 have to be changed; only those which manage dual-mode cameras. Adding a few ioctls to ask for and give up control at the appropriate times must be a lot easier than porting the entire driver into the kernel. Again, applications that won't implement this control will take the lock forever. No, because there is no lock. Programs that haven't been changed will continue to behave as they do today -- they will unbind the webcam driver and assume full control of the device. Alan Stern -- 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: USB mini-summit at LinuxCon Vancouver
On Thu, 11 Aug 2011, Alan Cox wrote: Actually there are more issues than that - you've also got to worry about a security/permission model, and that is hard to get right, especially if you are not very careful that anything that can be retrieved which might violate the security model (eg the last frame on the capture) has been blanked before handover etc. As far as I can tell, these same security issues exist today. I don't see them getting any worse than they are now. And applications that are touching both video (even indirectly) and still camera may get surprise deadlocks if they accidentally reference both the still and video device even via some library or service. No, not deadlocks. Just -EBUSY errors. Well, a user program can assume that the kernel driver left the device in a clean state. The reverse isn't always true, however -- it's one Not it cannot - the user program doesn't know a) if the kernel driver has ever been loaded b) the values the kernel driver leaves set (and those will change no doubt at times) c) if the camera has been plugged and unplugged and not yet had the kernel driver loaded That's true. The program can't assume that a kernel driver was ever bound to the device; all it can assume is that _if_ a kernel driver was bound then it left the device in a sane state -- whatever sane might mean in this context. To me it sounds like a recipe for disaster. For those tiny number of devices involved just use V4L and if need be some small V4L tweaks to handle still mode. In most cases the interface is basically identical and I'd bet much of the code is identical too. I'm not against moving the whole thing into the kernel. I'm just pointing out that an easier-to-code-up solution will accomplish much the same result. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] fbdev: Add FOURCC-based format configuration API
Hi Geert, On Monday 01 August 2011 11:49:46 Geert Uytterhoeven wrote: On Mon, Aug 1, 2011 at 00:54, Florian Tobias Schandinat wrote: On 07/31/2011 08:32 PM, Geert Uytterhoeven wrote: On Thu, Jul 28, 2011 at 12:51, Laurent Pinchart wrote: As for struct fb_var_screeninfo fields to support switching to a FOURCC mode, I also prefer an explicit dedicated flag to specify switching to it. Even though using FOURCC doesn't fit under the notion of a videomode, using one of .vmode bits is too tempting, so, I would actually take the plunge and use FB_VMODE_FOURCC. Another option would be to consider any grayscale 1 value as a FOURCC. I've briefly checked the in-tree drivers: they only assign grayscale with 0 or 1, and check whether grayscale is 0 or different than 0. If a userspace application only sets grayscale 1 when talking to a driver that supports the FOURCC-based API, we could get rid of the flag. What can't be easily found out is whether existing applications set grayscale to a 1 value. They would break when used with FOURCC-aware drivers if we consider any grayscale 1 value as a FOURCC. Is that a risk we can take ? I think we can. I'd expect applications to use either 1 or -1 (i.e. all ones), both are invalid FOURCC values. Still, I prefer the nonstd way. And limiting traditional nonstd values to the lowest 24 bits (there are no in-tree drivers using the highest 8 bits, right?). Okay, it would be okay for me to - write raw FOURCC values in nonstd, enable FOURCC mode if upper byte != 0 - not having an explicit flag to enable FOURCC - in FOURCC mode drivers must set visual to FB_VISUAL_FOURCC - making support of FOURCC visible to userspace by capabilites |= FB_CAP_FOURCC The capabilities is not strictly necessary but I think it's very useful as - it allows applications to make sure the extension is supported (for example to adjust the UI) - it allows applications to distinguish whether a particular format is not supported or FOURCC at all - it allows signaling further extensions of the API - it does not hurt, one line per driver and still some bytes in fixinfo free So using it would look like this: - the driver must have capabilities |= FB_CAP_FOURCC - the application may check capabilities to know whether FOURCC is supported - the application may write a raw FOURCC value in nonstd to request changing to FOURCC mode with this format - when the driver switches to a FOURCC mode it must have visual = FB_VISUAL_FOURCC and the current FOURCC format in nonstd - the application should check visual and nonstd to make sure it gets what it wanted As several of the FOURCC formats duplicate formats you can already specify in some other way (e.g. the RGB and greyscale formats), and as FOURCC makes life easier for the application writer, I'm wondering whether it makes sense to add FOURCC support in the generic layer for drivers that don't support it? I.e. the generic layer would fill in fb_var_screeninfo depending on the requested FOURCC mode, if possible. That's a good idea, but I'd like to add that in a second step. I'm working on a proof-of-concept by porting a driver to the FOURCC-based API first. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Media Subsystem Workshop 2011
Le lundi 8 août 2011 16:25:26 Mauro Carvalho Chehab, vous avez écrit : So the presentation and summary are on Tuesday, but when is the workshop itself? Is it on the Monday or the Sunday? It would be nice to know so I can plan my stay in Prague and my planning with the other conferences going on at the same time. The workshop itself will be on Sunday, and the presentations on Tuesday. Monday will be for KS/2011 only invitees. The LinuxCon and ELC Europe will start on Wed. So the workshop is only Sunday, is that right? Is it tied to any of the registration fees (LinuxCon is steep if you are not sponsored nor studying)? -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- 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: Media Subsystem Workshop 2011
Em 11-08-2011 14:49, Rémi Denis-Courmont escreveu: Le lundi 8 août 2011 16:25:26 Mauro Carvalho Chehab, vous avez écrit : So the presentation and summary are on Tuesday, but when is the workshop itself? Is it on the Monday or the Sunday? It would be nice to know so I can plan my stay in Prague and my planning with the other conferences going on at the same time. The workshop itself will be on Sunday, and the presentations on Tuesday. Monday will be for KS/2011 only invitees. The LinuxCon and ELC Europe will start on Wed. So the workshop is only Sunday, is that right? Sunday and Tuesday. The discussions will happen on Sunday. On Tuesday, we'll have the opportunity to exchange some information with the other people from KS and from the other workshops. As Monday will be free for most people, it probably makes sense to organize some informal meetings there for the ones that won't be at the KS only day. Is it tied to any of the registration fees (LinuxCon is steep if you are not sponsored nor studying)? No, but it requires an invitation, and I need to pass the names of the participants to KS organizers. So, please let me know if you intend to be there, for me to send you an invitation. Thanks, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build: WARNINGS
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:Thu Aug 11 19:00:32 CEST 2011 git hash:9bed77ee2fb46b74782d0d9d14b92e9d07f3df6e gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB mini-summit at LinuxCon Vancouver
On Thu, 11 Aug 2011, Alan Stern wrote: On Thu, 11 Aug 2011, Alan Cox wrote: Actually there are more issues than that - you've also got to worry about a security/permission model, and that is hard to get right, especially if you are not very careful that anything that can be retrieved which might violate the security model (eg the last frame on the capture) has been blanked before handover etc. As far as I can tell, these same security issues exist today. I don't see them getting any worse than they are now. And applications that are touching both video (even indirectly) and still camera may get surprise deadlocks if they accidentally reference both the still and video device even via some library or service. No, not deadlocks. Just -EBUSY errors. Well, a user program can assume that the kernel driver left the device in a clean state. The reverse isn't always true, however -- it's one Not it cannot - the user program doesn't know a) if the kernel driver has ever been loaded b) the values the kernel driver leaves set (and those will change no doubt at times) c) if the camera has been plugged and unplugged and not yet had the kernel driver loaded That's true. The program can't assume that a kernel driver was ever bound to the device; all it can assume is that _if_ a kernel driver was bound then it left the device in a sane state -- whatever sane might mean in this context. To me it sounds like a recipe for disaster. For those tiny number of devices involved just use V4L and if need be some small V4L tweaks to handle still mode. In most cases the interface is basically identical and I'd bet much of the code is identical too. I'm not against moving the whole thing into the kernel. I'm just pointing out that an easier-to-code-up solution will accomplish much the same result. Alan Stern Alan, As I said, I am agnostic, though leaning in the direction that Hans de Goede is pointing. What he says about a single control mechanism seems to make a lot of sense. If you can come up with an outline of the easier to code solution, that would be interesting, though. I assume you are also going to be in Vancouver? If you will be there on Monday, then Hans and I are already planning to meet and discuss. BTW, as to using V4L with tweaks to handle still mode, it would probably be more difficult than is imagined. For, though the operations required to process still images and webcam frames are in principle similar, the priorities and constraints are too different. Therefore, my understanding is that the libgphoto2 image processing routines, not the libv4l image processing routines, would still be used for still images. 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: USB mini-summit at LinuxCon Vancouver
Em 11-08-2011 17:01, Theodore Kilgore escreveu: As I said, I am agnostic, though leaning in the direction that Hans de Goede is pointing. What he says about a single control mechanism seems to make a lot of sense. If you can come up with an outline of the easier to code solution, that would be interesting, though. I assume you are also going to be in Vancouver? If you will be there on Monday, then Hans and I are already planning to meet and discuss. BTW, as to using V4L with tweaks to handle still mode, it would probably be more difficult than is imagined. For, though the operations required to process still images and webcam frames are in principle similar, the priorities and constraints are too different. Therefore, my understanding is that the libgphoto2 image processing routines, not the libv4l image processing routines, would still be used for still images. I agree with Alan Cox: most of the code that the driver needs is already there: register read/write routines, bulk transfer support, etc. The amount of extra code for adding still cam functionality is probably not big. From the kernel driver's perspective, it doesn't matter if the access will come via libv4l, libgphoto2 or whatever. The driver should be able to allow simultaneous open, while protecting the data access when userspace requests data stream or still image retrieve. instead of using the V4L2 device node to access the stored images, it probably makes more sense to use a separate device for that, that will handle a separate set of ioctl's, and just use read() to retrieve the image data, after selecting the desired image number, via ioctl(). It probably makes sense to add a new set of callbacks at the gspca core in order to handle the new device node, and letting it to avoid start streaming while the store access is happening, and vice-versa. Alternatively, we may create a separate still cam core library to handle the new device node,. If all agree around such solution, I suggest to take the most complex case and try to map it into the driver and core, and see how it behaves, testing with some simple command line applications, only changing the libgphoto2 code after those initial tests. Writing a simple code for reading still images should be easy, and we have already some testing tools for V4L2. After coding the core changes that are common to all drives, I suspect that adding the remaining 4 drivers will be quick. With regards to libgphoto2, all it needs to do is to test if the new device nodes exist. If they exist, then the new code will be used. Otherwise, it will fallback to the libusb. This way, we can incrementally add the Dual mode drivers into the kernel. There is one advantage on using this strategy: if, in the future, new Dual Cams arise, one can write first a still cam kernel driver, adding V4L support later. 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: S2-3200 switching-timeouts on 2.6.38
On 08/11/2011 01:49 AM, P. van Gaans wrote: On 03/21/2011 08:46 PM, Rico Tzschichholz wrote: Hello, I would like to know if there is any intention to include this patch soon? https://patchwork.kernel.org/patch/244201/ Currently using 2.6.38 results in switching-timeouts on my S2-3200 and this patch fixes this for good. So it would be nice to have it in 2.6.39. Thank you and best regards, Rico Tzschichholz Hello, I also have a Technotrend S2-3200. Bought it 4 years ago. Support for Linux seemed to be close at the time. I was a bit of a fool for thinking that. It's been on the shelf for most of the time. Anyway, I've applied that patch, and it turns the S2-3200 from being worth hardly more than a paperweight to a functional DVB-S card. I don't understand why this patch does not get included. Only DVB-S2 transponders don't consistently lock properly in kaffeine. I'll test what scan does tomorrow, see if it's a kaffeine-specific problem or not. But even just DVB-S working properly is a massive difference for this card. If it helps, I'll check the silicon version of my card tomorrow as well. Best regards, P. van Gaans -- 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 Hello, Here I am again. My card can be seen at http://tinypic.com/r/2hewzyu/7 Chip: C2L STB0899 VQ628NDY 220QQ VQ MLT 22 645 So far, scan-s2 won't compile: scan.c:51:2: error: #error scan-s2 requires Linux DVB driver API version 5.0! (I am doing something wrong undoubtedly) and I cannot find a way to make w_scan scan specific frequencies. It must be possible, but right now I can't figure it out. Scan doesn't support DVB-S2. Perhaps someone else who has an S2-3200 can test this, if not, I will eventually get to it I guess, but I'm not entirely sure when. Best regards, Pim -- 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: omap3isp buffer alignment
On Thu, Aug 11, 2011 at 11:57:04AM +0200, Michael Jones wrote: Hi Laurent, If I understood your discussion with Russell [1] correctly, user pointer buffers are required to be page-aligned because of the IOMMU API, and it's desirable to keep the IOMMU driver that way for other subsystems which may use it. So we're stuck with user buffers needing to be page-aligned. My understanding is that this is actually a hardware requirement. You only can map pages of 4 kiB (at least). There's a check in ispvideo.c:isp_video_buffer_prepare() that the buffer address is 32-byte aligned. Isn't this superfluous considering the page-aligned restriction? I guess the ISP driver isn't assuming that ispmmu_vmap always give page aligned mappings --- or that the page size couls theoretically be smaller. The assumptions might not hold in another implementation of the IOMMU API, which however will be replaced (hopefully at some point) by the improved DMA mapping API. Cheers, -- Sakari Ailus sakari.ai...@iki.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: USB mini-summit at LinuxCon Vancouver
On Thu, 11 Aug 2011, Mauro Carvalho Chehab wrote: Em 11-08-2011 17:01, Theodore Kilgore escreveu: As I said, I am agnostic, though leaning in the direction that Hans de Goede is pointing. What he says about a single control mechanism seems to make a lot of sense. If you can come up with an outline of the easier to code solution, that would be interesting, though. I assume you are also going to be in Vancouver? If you will be there on Monday, then Hans and I are already planning to meet and discuss. BTW, as to using V4L with tweaks to handle still mode, it would probably be more difficult than is imagined. For, though the operations required to process still images and webcam frames are in principle similar, the priorities and constraints are too different. Therefore, my understanding is that the libgphoto2 image processing routines, not the libv4l image processing routines, would still be used for still images. I agree with Alan Cox: most of the code that the driver needs is already there: register read/write routines, bulk transfer support, etc. The amount of extra code for adding still cam functionality is probably not big. From the kernel driver's perspective, it doesn't matter if the access will come via libv4l, libgphoto2 or whatever. The driver should be able to allow simultaneous open, while protecting the data access when userspace requests data stream or still image retrieve. instead of using the V4L2 device node to access the stored images, it probably makes more sense to use a separate device for that, that will handle a separate set of ioctl's, and just use read() to retrieve the image data, after selecting the desired image number, via ioctl(). It probably makes sense to add a new set of callbacks at the gspca core in order to handle the new device node, and letting it to avoid start streaming while the store access is happening, and vice-versa. Alternatively, we may create a separate still cam core library to handle the new device node,. If all agree around such solution, I suggest to take the most complex case and try to map it into the driver and core, and see how it behaves, testing with some simple command line applications, only changing the libgphoto2 code after those initial tests. Writing a simple code for reading still images should be easy, and we have already some testing tools for V4L2. After coding the core changes that are common to all drives, I suspect that adding the remaining 4 drivers will be quick. With regards to libgphoto2, all it needs to do is to test if the new device nodes exist. If they exist, then the new code will be used. Otherwise, it will fallback to the libusb. This way, we can incrementally add the Dual mode drivers into the kernel. There is one advantage on using this strategy: if, in the future, new Dual Cams arise, one can write first a still cam kernel driver, adding V4L support later. Cheers, Mauro Try it out with one camera seems to me to be a reasonable way forward. 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: USB mini-summit at LinuxCon Vancouver
On Thu, 11 Aug 2011, Theodore Kilgore wrote: Alan, As I said, I am agnostic, though leaning in the direction that Hans de Goede is pointing. What he says about a single control mechanism seems to make a lot of sense. If you can come up with an outline of the easier to code solution, that would be interesting, though. That approach has been outlined in the other emails I have posted recently. I assume you are also going to be in Vancouver? If you will be there on Monday, then Hans and I are already planning to meet and discuss. No, I'm not going to Vancouver. However I will attend the Linux Plumbers conference in Santa Rosa. Alan Stern -- 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: USB mini-summit at LinuxCon Vancouver
On Thu, 11 Aug 2011, Alan Stern wrote: snip No, I'm not going to Vancouver. Well, someday, somewhere, we will be together in the same place at the same time and able to enjoy a good seafood restaurant. However I will attend the Linux Plumbers conference in Santa Rosa. Which I expect I will not. Until next time we meet, cheers. 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
