Lines Matching refs:you
21 If you embed it in a larger struct, then you must set the ``release()``
54 - :c:type:`video_device`->ioctl_ops: if you use the :c:type:`v4l2_ioctl_ops`
64 - :c:type:`video_device`->lock: leave to ``NULL`` if you want to do all the
65 locking in the driver. Otherwise you give it a pointer to a struct
85 in :c:type:`v4l2_device`. If you want to have a separate priority state per
86 (group of) device node(s), then you can point it to your own struct
89 - :c:type:`video_device`->dev_parent: you only set this if v4l2_device was
98 struct video_device is initialized you **do** know which parent
99 PCI device to use and so you set ``dev_device`` to the correct PCI device.
101 If you use :c:type:`v4l2_ioctl_ops`, then you should set
105 In some cases you want to tell the core that a function you had specified in
113 being used) you want to turns off certain features in :c:type:`v4l2_ioctl_ops`
120 If integration with the media framework is needed, you must initialize the
142 If you set this pointer, then that will be used by unlocked_ioctl to
145 If you are using the :ref:`videobuf2 framework <vb2_framework>`, then there
146 is a second lock that you can set: :c:type:`video_device`->queue->lock. If
153 can take a long time, so you want to use a separate lock for the buffer queuing
157 Of course, you can always do all the locking yourself by leaving both lock
160 If you use the old :ref:`videobuf framework <vb_framework>` then you must
164 waits in the code, then you should do the same to allow other
168 In the case of :ref:`videobuf2 <vb2_framework>` you will need to implement the
170 If you use the ``queue->lock`` pointer, then you can use the helper functions
174 :c:type:`video_device` before calling v4l2_device_disconnect. If you are also
175 using :c:type:`video_device`->queue->lock, then you have to first lock
177 That way you can be sure no ioctl is running when you call
183 Next you register the video device with :c:func:`video_register_device`.
184 This will create the character device for you.
214 The last argument gives you a certain amount of control over the device
215 device node number used (i.e. the X in ``videoX``). Normally you will pass -1
227 So you can use the last argument to specify a minimum device node number
229 or higher to what you passed. If that fails, then it will just pick the
232 Since in this case you do not care about a warning about not being able
233 to select the specified device node number, you can call the function
236 Whenever a device node is created some attributes are also created for you.
237 If you look in ``/sys/class/video4linux`` you see the devices. Go into e.g.
238 ``video0`` and you will see 'name', 'dev_debug' and 'index' attributes. The
245 first video device node you register always starts with index 0.
250 After the device was successfully registered, then you can use these fields:
259 If the registration failed, then you need to call
263 failed, nor should you ever attempt to unregister the device if the
270 device in ``/sys/class/video4linux/<devX>/`` allows you to enable logging of
298 of the driver or because the USB device was disconnected, then you should
313 callback is called and you can do the final cleanup there.
339 Note that you can safely call :c:func:`video_set_drvdata` before calling