lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 15 May 2008 08:34:42 -0700
From:	Dean Anderson <dean@...soray.com>
To:	Trent Piepho <xyzzy@...akeasy.org>
CC:	Greg KH <greg@...ah.com>,
	Markus Rechberger <mrechberger@...il.com>,
	video4linux-list@...hat.com, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org, mchehab@...radead.org,
	v4l-dvb-maintainer@...uxtv.org
Subject: Re: [v4l-dvb-maintainer] [PATCH] USB: add Sensoray 2255 v4l driver

Trent Piepho wrote:
> On Wed, 14 May 2008, Greg KH wrote:
>   
>> On Thu, May 15, 2008 at 03:17:42AM +0200, Markus Rechberger wrote:
>>     
>>> Hi Dean, Greg,
>>>       
>> Adding dean to the cc: line...  :)
>>     
>>> On 5/14/08, Greg KH <greg@...ah.com> wrote:
>>>       
>>>> From: Dean Anderson <dean@...soray.com>
>>>>
>>>>         
>> <big patch snipped>
>>
>>     
>>> Why do you do those conversions in kernelspace?
>>> ffmpeg/libswscale has optimized code for colourspace conversions.
>>> I know a few drivers do that in kernelspace but it's way more flexible
>>> in userspace and depending on the optimization requires less CPU
>>> power.
>>>       
>> I thought they were there as needed by some V4L1 applications, but that
>> code was recently removed by Dean I think.  If they don't need to be
>> there, and userspace apps can properly handle the different colorspace,
>> then I'll be glad to remove them.
>>     
>
> Virtually all apps (V4L1 & 2) can handle YUV and RGB colorspaces.
> Certainly all the major ones do and all the major libraries as well.
>
> The problem is when the device only supports some vendor specific or
> otherwise very uncommon format.  In that case not doing the conversion in
> the kernel means the device won't work with any existing software without
> patches.  In this case, while it's not "the right way", drivers often end
> up including an in kernel conversion for pragmatic reasons.
>
> This was a problem with the bayer format, but now userspace support for
> that format is more common.
>   

I agree the conversions don't belong in a driver. For the record, the 
following are done in the 2255 hardware: V4L2_PIX_FMT_GREY and 
V4L2_PIX_FMT_YUV422P.

Since planar YUV formats such as V4L2_PIX_FMT_YUV422P are still not that 
well supported, is it possible to keep at least one packed YUV 
format(V4L2_PIX_FMT_YUYV) in the driver?  If not, let me know.  I will 
strongly suggest that the hardware Engineers add YUY2 or YUYV on board 
in the DSP firmware.  Thanks, Dean










--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ