Lines Matching refs:you
19 If you embed it in a larger struct, then you must set the ``release()``
52 - :c:type:`video_device`->ioctl_ops: if you use the :c:type:`v4l2_ioctl_ops`
62 - :c:type:`video_device`->lock: leave to ``NULL`` if you want to do all the
63 locking in the driver. Otherwise you give it a pointer to a struct
83 in :c:type:`v4l2_device`. If you want to have a separate priority state per
84 (group of) device node(s), then you can point it to your own struct
87 - :c:type:`video_device`->dev_parent: you only set this if v4l2_device was
96 struct :c:type:`video_device` is initialized you **do** know which parent
97 PCI device to use and so you set ``dev_device`` to the correct PCI device.
99 If you use :c:type:`v4l2_ioctl_ops`, then you should set
103 In some cases you want to tell the core that a function you had specified in
111 being used) you want to turns off certain features in :c:type:`v4l2_ioctl_ops`
118 If integration with the media framework is needed, you must initialize the
140 If you set this pointer, then that will be used by unlocked_ioctl to
143 If you are using the :ref:`videobuf2 framework <vb2_framework>`, then there
144 is a second lock that you can set: :c:type:`video_device`->queue->lock. If
151 can take a long time, so you want to use a separate lock for the buffer queuing
155 Of course, you can always do all the locking yourself by leaving both lock
158 If you use the old :ref:`videobuf framework <vb_framework>` then you must
162 waits in the code, then you should do the same to allow other
166 In the case of :ref:`videobuf2 <vb2_framework>` you will need to implement the
168 If you use the ``queue->lock`` pointer, then you can use the helper functions
172 :c:type:`video_device` before calling v4l2_device_disconnect. If you are also
173 using :c:type:`video_device`->queue->lock, then you have to first lock
175 That way you can be sure no ioctl is running when you call
181 Next you register the video device with :c:func:`video_register_device`.
182 This will create the character device for you.
212 The last argument gives you a certain amount of control over the device
213 device node number used (i.e. the X in ``videoX``). Normally you will pass -1
225 So you can use the last argument to specify a minimum device node number
227 or higher to what you passed. If that fails, then it will just pick the
230 Since in this case you do not care about a warning about not being able
231 to select the specified device node number, you can call the function
234 Whenever a device node is created some attributes are also created for you.
235 If you look in ``/sys/class/video4linux`` you see the devices. Go into e.g.
236 ``video0`` and you will see 'name', 'dev_debug' and 'index' attributes. The
243 first video device node you register always starts with index 0.
248 After the device was successfully registered, then you can use these fields:
257 If the registration failed, then you need to call
261 failed, nor should you ever attempt to unregister the device if the
268 device in ``/sys/class/video4linux/<devX>/`` allows you to enable logging of
295 of the driver or because the USB device was disconnected, then you should
310 callback is called and you can do the final cleanup there.
336 Note that you can safely call :c:func:`video_set_drvdata` before calling