Re: [RFC PATCH 1/2] sn9c102: prepare for removal by moving it to staging.

[Luca Risolia]

Hi Hans,

thanks for your reply. I understand your point of view. Since the sn9c102 will 
be removed from the kernel soon, I am considering another option, that is to 
move the driver to UV4L, which is a transparent, ~100% userspace 
implementation of V4L2-compliant drivers for input devices.

So, for those who are still interested in good support for the sn9cxxx, I'll 
be porting all the code to userspace. Users will not notice any difference 
from a kernel driver. Fore more informations:

http://linux-projects.org

Regards,
Luca

In data domenica 15 dicembre 2013 12:18:17, Hans Verkuil ha scritto:
 Hi Luca,
 
 On 12/14/2013 06:13 PM, Luca Risolia wrote:
  From: Hans Verkuil hans.verk...@cisco.com
  
  During the last media summit meeting it was decided to move this driver
  to
  staging as the first step to removing it altogether.
  
  Most webcams covered by this driver are now supported by gspca. Nobody
  has
  the hardware to convert the remaining devices to gspca.
  
  I have all the boards given by the manufacturer. Last time I tried the
  gspca driver it certainly did not work with most of the sn9c1xx-based
  models the gspca driver claims to be supporting (which were a subset of
  the devices actually supported by sn9c102).
  
  This driver needs a major overhaul to have it conform to the latest
  frameworks and compliancy tests.
  
  What is not compliant? I will offer my help to update the driver in case
  but cannot give my help to fix or test all the boards again with the
  gspca, as it would be a considerable amount of extra work.
 
 Work is ongoing to move all drivers to the latest V4L2 frameworks (control
 framework, using v4l2_fh, v4l2_device, video_ioctl2  unlocked_ioctl,
 videobuf2 were possible). This reduces code complexity of the drivers and
 will eventually allow us to get rid of old core legacy code. In addition,
 using these frameworks will help drivers to pass the v4l2-compliance test
 tool (part of v4l-utils.git).
 
 For most drivers not yet converted I have hardware myself that I can use to
 do the conversion and testing, but not for the sn9c102.
 
 Given the fact that that driver caters to very old webcams that few people
 use, and for which cheap modern webcam replacements are easily available,
 it is the opinion of the core v4l2 developers that it is not worth the
 effort for us to convert the driver.
 
 The first step in that process is to move it to staging to signal that
 unless something is done this driver will be removed.
 
 There are a number of options:
 
 1) Nothing is done. In that case the driver will be removed, probably end of
 next year.
 2) You convert the driver to the various frameworks, make it pass
 v4l2-compliance, etc. In that case there is no reason to remove it.
 3) My estimate is that option 2) is time consuming. It might be easier for
 you to add support for the webcams to gspca instead.
 4) Send the webcams that are not (or not correctly) supported by gscpa to
 Hans de Goede, and let him add support for them to gspca. I don't know if
 he wants to, though. He may well decide that it is not worth it, although I
 assume he would be willing to at least fix gspca for webcams that are not
 correctly supported.
 
  Without hardware, however, this is next to impossible. Given the fact
  that
  this driver seems to be pretty much unused (it has been removed from
  Fedora
  several versions ago and nobody complained about that), we decided to
  drop
  this driver.
  
  As no one has the hardware, what is the reason why the sn9c102 has been
  moved into gspca, although the sn9c102 driver has been already present in
  the kernel since years before?
 
 Frankly because sn9c102 isn't very good code. In all fairness, none of
 todays frameworks existed when sn9c102 was first created. It would be done
 quite differently today. Note that AFAIK HdG has some of the webcams
 supported by both gspca and sn9c102, I'm assuming those are working fine
 with gspca.
  In my opinion the fact that the module has been removed from Fedora does
  not imply that the driver is unused. For sure that does not mean the
  sn9c102 driver is unuseful, since gspca does not work properly with all
  the devices, as I mentioned.
 
 The fact that nobody has been complaining about the removal from Fedora
 indicates that very few people still use the webcams supported by sn9c102.
 
 That in itself is not a problem, but the fact that the code is really old
 and needs a lot of work is. Within 1-2 years I am going to require that all
 V4L2 drivers use at least some of the core frameworks in order to enforce
 consistent API behavior. sn9c102 is one of the very few drivers that has
 the unlucky combination of being too complex to easily/quickly convert, is
 only rarely used, and for which there is a cheap and easy upgrade path for
 the few remaining users (if any) of that driver (i.e. buy a uvc webcam).
 
 We have removed drivers in the past as well for similar reasons. It's done
 very rarely: only

Re: [RFC PATCH 1/2] sn9c102: prepare for removal by moving it to staging.

[Luca Risolia]

 From: Hans Verkuil hans.verk...@cisco.com
 
 During the last media summit meeting it was decided to move this driver to
 staging as the first step to removing it altogether.
 
 Most webcams covered by this driver are now supported by gspca. Nobody has
 the hardware to convert the remaining devices to gspca.

I have all the boards given by the manufacturer. Last time I tried the gspca 
driver it certainly did not work with most of the sn9c1xx-based models the 
gspca driver claims to be supporting (which were a subset of the devices 
actually supported by sn9c102).

 This driver needs a major overhaul to have it conform to the latest
 frameworks and compliancy tests.

What is not compliant? I will offer my help to update the driver in case but 
cannot give my help to fix or test all the boards again with the gspca, as it 
would be a considerable amount of extra work.

 Without hardware, however, this is next to impossible. Given the fact that
 this driver seems to be pretty much unused (it has been removed from Fedora
 several versions ago and nobody complained about that), we decided to drop
 this driver.

As no one has the hardware, what is the reason why the sn9c102 has been moved 
into gspca, although the sn9c102 driver has been already present in the kernel 
since years before?

In my opinion the fact that the module has been removed from Fedora does not 
imply that the driver is unused. For sure that does not mean the sn9c102 
driver is unuseful, since gspca does not work properly with all the devices, 
as I mentioned.

Regards
Luca

--
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

User space Video4Linux drivers

[Luca Risolia]

Hello,

for those who might be interested in user space
Video4Linux drivers, here is UV4L:

http://linux-projects.org

UV4L stands for Userspace Video4Linux framework. It consists of a core
module which loads a specified Video4Linux driver as plug-in.
Each instance of a driver is exactly one process. Drivers can implement
real or virtual video input devices.

No special help from the kernel is required for controlling the
devices and applications should work transparently.

For now two drivers have been developed:
- UVC, for video devices based on the Usb Video Class specification.
- XScreen, a virtual device capturing a given portion of an X screen.

The support for UVC-based hardware is minimal at the moment.

Packages for Ubuntu Raring 13.04 can be installed by following
these instructions:

http://www.linux-projects.org/listing/uv4l_repo/INSTALL

Once they have been installed, man uv4l should give
more details about the use of uv4l and its features.

--

--
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: [RFC] JPEG encoders control class

[Luca Risolia]

Hans Verkuil ha scritto:

On Saturday 12 November 2011 20:46:25 Sylwester Nawrocki wrote:

Hi all,

This RFC is discussing the current support of JPEG encoders in V4L2 and
a proposal of new JPEG control class.


Motivation
==

JPEG encoder control is also required at the sub-device level, but
currently there are only defined ioctls in regular V4L2 device API. It
doesn't seem to make sense for these current ioctls to be inherited by
sub-device nodes, since they're not generic enough, incomplete and rather
not compliant with JFIF JPEG standard [2], [3].


Current implementation
==

Currently two ioctls are available [4]:

#define VIDIOC_G_JPEGCOMP_IOR('V', 61, struct v4l2_jpegcompression)
#define VIDIOC_S_JPEGCOMP_IOW('V', 62, struct v4l2_jpegcompression)

And the corresponding data structure is defined as:

struct v4l2_jpegcompression {
int quality;

int  APPn;  /* Number of APP segment to be written,
 * must be 0..15 */
int  APP_len;   /* Length of data in JPEG APPn segment */
char APP_data[60];  /* Data in the JPEG APPn segment. */

int  COM_len;   /* Length of data in JPEG COM segment */
char COM_data[60];  /* Data in JPEG COM segment */

__u32 jpeg_markers; /* Which markers should go into the JPEG
 * output. Unless you exactly know what
 * you do, leave them untouched.
 * Inluding less markers will make the
 * resulting code smaller, but there will
 * be fewer applications which can read it.
 * The presence of the APP and COM marker
 * is influenced by APP_len and COM_len
 * ONLY, not by this property! */

#define V4L2_JPEG_MARKER_DHT (13)/* Define Huffman Tables */
#define V4L2_JPEG_MARKER_DQT (14)/* Define Quantization Tables */
#define V4L2_JPEG_MARKER_DRI (15)/* Define Restart Interval */
#define V4L2_JPEG_MARKER_COM (16)/* Comment segment */
#define V4L2_JPEG_MARKER_APP (17)/* App segment, driver will
* allways use APP0 */
};


What are the issues with such an implementation ?

These ioctls don't allow to re-program the quantization and Huffman tables
(DQT, DHT). Additionally, the standard valid segment length for the
application defined APPn and the comment COM segment is 2...65535, while
currently this is limited to 60 bytes.

Therefore APP_data and COM_data, rather than fixed size arrays, should be
pointers to a variable length buffer.

Only two drivers upstream really use VIDIOC_[S/G]_JPEGCOMP ioctls for
anything more than compression quality query/control. It might make sense
to create separate control for image quality and to obsolete the
v4l2_jpegcompressin::quality field.

Below is a brief review of usage of VIDIOC_[S/G]_JPEGCOMP ioctls in current
mainline drivers. Listed are parts of struct v4l2_jpegcompression used in
each case.


cpia2
-

vidioc_g_jpegcomp, vidioc_s_jpegcomp
- compression quality ignored, returns fixed value (80)
- uses APP_data/len, COM_data/len
- markers (only DHT can be disabled by the applications)


zoran
-

vidioc_g_jpegcomp, vidioc_s_jpegcomp
- compression quality, values 5...100, used only to calculate buffer size
- APP_data/len, COM_data/len
- markers field used to control inclusion of selected JPEG markers
  in the output buffer


et61x251, sn9c102, s2255drv.c
-


Note that et61x251 and sn9c102 are going to be deprecated and removed at some
time in the future (gspca will support these devices).


Has this been discussed yet? Also, last time I tried the gspca driver 
with a number of V4L2-compliant applications, it did not support at all 
or work well for all the sn9c1xx-based devices I have here, which are 
both controllers and sensors the manufacturer sent to me when developing 
the driver with their collaboration. I also don't understand why the 
gspca driver has been accepted in the mainline kernel in the first 
place, despite the fact the sn9c1xx has been present in the kernel since 
long time and already supported many devices at the time the gspca was 
submitted. Maybe it's better to remove the duplicate code form the gspca 
driver and add the different parts (if any) to the sn9c1xx.


Regards
Luca

--
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 07/20] video: sn9c102: world-wirtable sysfs files

[Luca Risolia]

Thanks.

Acked-by: Luca Risolia luca.riso...@studio.unibo.it

Vasiliy Kulikov ha scritto:

Don't allow everybody to change video settings.

Signed-off-by: Vasiliy Kulikov seg...@openwall.com
---
 Compile tested only.

 drivers/media/video/sn9c102/sn9c102_core.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/video/sn9c102/sn9c102_core.c 
b/drivers/media/video/sn9c102/sn9c102_core.c
index 84984f6..ce56a1c 100644
--- a/drivers/media/video/sn9c102/sn9c102_core.c
+++ b/drivers/media/video/sn9c102/sn9c102_core.c
@@ -1430,9 +1430,9 @@ static DEVICE_ATTR(i2c_reg, S_IRUGO | S_IWUSR,
   sn9c102_show_i2c_reg, sn9c102_store_i2c_reg);
 static DEVICE_ATTR(i2c_val, S_IRUGO | S_IWUSR,
   sn9c102_show_i2c_val, sn9c102_store_i2c_val);
-static DEVICE_ATTR(green, S_IWUGO, NULL, sn9c102_store_green);
-static DEVICE_ATTR(blue, S_IWUGO, NULL, sn9c102_store_blue);
-static DEVICE_ATTR(red, S_IWUGO, NULL, sn9c102_store_red);
+static DEVICE_ATTR(green, S_IWUSR, NULL, sn9c102_store_green);
+static DEVICE_ATTR(blue, S_IWUSR, NULL, sn9c102_store_blue);
+static DEVICE_ATTR(red, S_IWUSR, NULL, sn9c102_store_red);
 static DEVICE_ATTR(frame_header, S_IRUGO, sn9c102_show_frame_header, NULL);
 
 

--
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