- 27 Jul, 2011 40 commits
-
-
Hans Verkuil authored
Whenever a control changes value or state an event is sent to anyone that subscribed to it. This functionality is useful for control panels but also for applications that need to wait for (usually status) controls to change value. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
Hans Verkuil authored
When an application changes a control you want to generate an event. However, you want to avoid sending such an event back to the application (file handle) that caused the change. Add the filehandle to the various set control functions. The filehandle isn't used yet, but the control event patches will need this. Signed-off-by:
-
Hans Verkuil authored
Signed-off-by:
-
Hans Verkuil authored
Signed-off-by:
-
Hans Verkuil authored
It is a bit tricky to handle autogain/gain type scenerios correctly. Such controls need to be clustered and the V4L2_CTRL_FLAG_UPDATE should be set on the autofoo controls. In addition, the manual controls should be marked inactive when the automatic mode is on, and active when the manual mode is on. This also requires specialized volatile handling. The chances of drivers doing all these things correctly are pretty remote. So a new v4l2_ctrl_auto_cluster function was added that takes care of these issues. Signed-off-by:
-
Hans Verkuil authored
Signed-off-by:
-
Hans Verkuil authored
If you have a cluster of controls that is a mix of volatile and non-volatile controls, then requesting the value of the volatile control would fail if the master control of that cluster was non-volatile. The code assumed that the volatile state of the master control was the same for all other controls in the cluster. This is now fixed. In addition, it was clear from bugs in some drivers that it was confusing that the ctrl->cur union had to be used in g_volatile_ctrl. Several drivers used the 'new' values instead. The framework was changed so that drivers now set the new value instead of the current value. This has an additional benefit as well: the volatile values are now only stored in the 'new' value, leaving the current value alone. This is useful for autofoo/foo control clusters where you want to have a 'foo' control act like a volatile control if 'autofoo' is on, but as a normal control when it is off. Since with this change the cur value is no longer overwritten when g_volatile_ctrl is called, you can use it to remember the original 'foo' value. For example: autofoo = 0, foo = 10 and foo is non-volatile. Now autofoo is set to 1 and foo is marked volatile. Retrieving the foo value will get the volatile value. Set autofoo back to 0, which marks foo as non- volatile again, and retrieving foo will get the old current value of 10. Signed-off-by:
-
Hans Verkuil authored
To be consistent with v4l2-ioctl.c. Signed-off-by:
-
Hans Verkuil authored
This is required to implement control events and is also needed to allow for per-filehandle control handlers. Signed-off-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
-
Hans Verkuil authored
When applications try to set READ_ONLY controls an error should be returned. However, when drivers do that it should be accepted. Those controls could reflect some driver status which the application can't change but the driver obviously has to be able to change it. This is needed among others for future HDMI status controls. Signed-off-by:
-
Hans Verkuil authored
The lower-level prepare functions just set error_idx for each control that might have an error. The high-level functions will override this with cs->count in the get and set cases. Only try will keep the error_idx. Signed-off-by:
-
Hans Verkuil authored
Add the call_op define to safely call the control ops. This also allows for controls without any ops such as the 'control class' controls. Signed-off-by:
-
Mauro Carvalho Chehab authored
Acked-by:
-
Mauro Carvalho Chehab authored
Just like the video drivers, the right thing to do is to use the per-subsystem version control. Acked-by:
-
Mauro Carvalho Chehab authored
Standardize the remaining video drivers to return the API version for the VIDIOC_QUERYCAP version, instead of a per-driver version. Those drivers had the version updated more recently or are SoC drivers. Even so, it doesn't sound a good idea to keep a per-driver version control, so, let's use the per-subsystem version control instead. Acked-by:
-
Mauro Carvalho Chehab authored
Instead of handling a per-driver driver version, use the per-subsystem one. As reviewed by Jean-Francois Moine <moinejf@free.fr>: - the 'info' may be simplified: Reviewed-by:
Jean-Francois Moine <moinejf@free.fr> Acked-by:
-
Mauro Carvalho Chehab authored
uvcvideo doesn't use vidioc_ioctl2. As the API is changing to use a common version for all drivers, we need to expliticly fix this driver. Acked-by:
-
Mauro Carvalho Chehab authored
sn9c102 doesn't use vidioc_ioctl2. As the API is changing to use a common version for all drivers, we need to expliticly fix this driver. Acked-by:
-
Mauro Carvalho Chehab authored
pvrusb2 doesn't use vidioc_ioctl2. As the API is changing to use a common version for all drivers, we need to expliticly fix this driver. Acked-by:
-
Mauro Carvalho Chehab authored
et61x251 doesn't use vidioc_ioctl2. As the API is changing to use a common version for all drivers, we need to expliticly fix this driver. Acked-by:
-
Mauro Carvalho Chehab authored
After discussing with Andy Walls on irc, we've agreed that this is the best thing to do. No regressions will be introduced, as 3.x.y is greater then the current versions for cx18 and ivtv. Acked-by:
-
Mauro Carvalho Chehab authored
After discussing with Hans, change pwc to use the default version control. The only version ever used for pwc driver is 10.0.12, due to commit 2b455db6. Changing it to 3.x.y won't conflict with the old version. There's no namespace conflicts in any predictable future. Even on the remote far-away case where we might have a conflict, it will be on just one specific stable Kernel release (Kernel 10.0.12), if we ever have such stable release. So, it is safe and consistent on using 3.x.y numering schema for it. Acked-by:
-
Mauro Carvalho Chehab authored
All the modified drivers didn't have any version increment since Jan, 1 2011. Several of them didn't have any version increment for a long time, even having new features and important bug fixes happening. As we're now filling the QUERYCAP version with the current Kernel Release, we don't need to maintain a per-driver version control anymore. So, let's just use the default. In order to preserve the Kernel module version history, a KERNEL_VERSION() macro were added to all modified drivers, and the extraver number were incremented. I opted to preserve the per-driver version control to a few pwc, pvrusb2, s2255, s5p-fimc and sh_vou. A few drivers are still using the legacy way to handle ioctl's. So, we can't do such change on them, otherwise, they'll break. Those are: uvc, et61x251 and sn9c102. The rationale is that the per-driver version control seems to be actively maintained on those. Yet, I think that the better for them would be to just use the default version numbering, instead of doing that by themselves. While here, removed a few uneeded include linux/version.h Acked-by:
-
Mauro Carvalho Chehab authored
Both drxd and siano drivers were including linux/version.h without any reason. Probably, this is due to some compatibility code that used to exist before having their support added into the Linux Kernel. Acked-by:
-
Mauro Carvalho Chehab authored
Most drivers don't increase kernel versions as newer features are added or bug fixes are solved. So, vidioc_querycap returned value for cap->version is meaningless. Instead of keeping this situation forever, let's add a default value matching the current Linux version. Drivers that want to keep their own version control can still do it, as they can override the default value for cap->version. Acked-by:
-
Mauro Carvalho Chehab authored
The old V4L1 Kernel copatibility layer was removed, but the API spec still says that it is there. Signed-off-by: -
Jonathan Corbet authored
The core driver can now operate in either vmalloc or dma-contig modes; obviously the latter is preferable when it is supported. Default is currently vmalloc on all platforms; load the module with buffer_mode=1 for contiguous DMA mode. Signed-off-by:
Jonathan Corbet <corbet@lwn.net> Signed-off-by:
-
Jonathan Corbet authored
The sequence numbers already give that information if user space cares; this is a frequent occurrence on slower machines, alas. Signed-off-by:
-
Jonathan Corbet authored
This was an old debugging thing from years ago. It's only done at initialization time, but it's still unnecessary; take it out. Signed-off-by:
-
Jonathan Corbet authored
Put the includes into a slightly more readable ordering and get rid of a few unneeded ones. Signed-off-by:
-
Jonathan Corbet authored
This is a basic, naive conversion to the videobuf2 infrastructure, removing a lot of code in the process. For now, we're using vmalloc, which is suboptimal, but it does match what the cafe driver did before. In the cafe case, it may have to stay that way just because memory is too tight to do direct streaming; mmp-camera will be able to do better. Signed-off-by:
-
Sylwester Nawrocki authored
Signed-off-by:
Sylwester Nawrocki <snjw23@gmail.com> Signed-off-by:
-
Manjunath Hadli authored
Please refer to this file for detailed documentation of davinci vpbe v4l2 driver. Signed-off-by:
Manjunath Hadli <manjunath.hadli@ti.com> Acked-by:
Muralidharan Karicheri <m-karicheri2@ti.com> Acked-by:
-
Manjunath Hadli authored
This patch adds the build infra-structure for Davinci VPBE dislay driver. Signed-off-by:
-
Manjunath Hadli authored
This patch adds the VENC or the Video encoder, which is responsible for the blending of all source planes and timing generation for Video modes like NTSC, PAL and other digital outputs. the VENC implementation currently supports COMPOSITE and COMPONENT outputs and NTSC and PAL resolutions through the analog DACs. The venc block is implemented as a subdevice, allowing for additional external and internal encoders of other kind to plug-in. Signed-off-by:
-
Manjunath Hadli authored
This patch implements the functionality of the OSD block of the VPBE. The OSD in total supports 4 planes or Video sources - 2 mainly RGB and 2 Video. The patch implements general handling of all the planes, with specific emphasis on the Video plane capabilities as the Video planes are supported through the V4L2 driver. Signed-off-by:
-
Manjunath Hadli authored
This patch implements the core functionality of the display driver, mainly controlling the VENC and other encoders, and acting as the one point interface for the main V4L2 driver. This implements the core of each of the V4L2 IOCTLs. Signed-off-by:
-
Manjunath Hadli authored
This is the display driver for Texas Instruments's DM644X family SoC. This patch contains the main implementation of the driver with the V4L2 interface. The driver implements the streaming model with support for both kernel allocated buffers and user pointers. It also implements all of the necessary IOCTLs necessary and supported by the video display device. Signed-off-by:
-
Jiri Slaby authored
Telling the user they can disable an option if they want is not the much useful. Describe what it is good for instead. The text was derived from Mauro's email. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Cc: Mauro Carvalho Chehab <mchehab@redhat.com> Cc: Hans Petter Selasky <hselasky@c2i.net> Acked-by:
Randy Dunlap <randy.dunlap@oracle.com> Acked-by:
Hans Petter Selasky <hselasky@c2i.net> Signed-off-by:
-
Greg Dietsche authored
remove unnecessary code that matches this coccinelle pattern if (...) return ret; return ret; Signed-off-by:
Greg Dietsche <Gregory.Dietsche@cuw.edu> Signed-off-by:
-
