[PATCH 0/2] media-ctl: minor changes
Hi Laurent, These are a couple of commits that I have locally on top of your media-ctl head which I would like to see in your rep. Michael Jones (2): add Y10, Y12 formats try using autoconf 2.61 configure.in |2 +- src/main.c |2 ++ 2 files changed, 3 insertions(+), 1 deletions(-) -- 1.7.5.4 MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner -- 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
[PATCH 1/2] add Y10, Y12 formats
Signed-off-by: Michael Jones michael.jo...@matrix-vision.de
---
I added these when playing around with the shifter.
src/main.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/main.c b/src/main.c
index 35c34a2..b9b9150 100644
--- a/src/main.c
+++ b/src/main.c
@@ -50,6 +50,8 @@ static struct {
enum v4l2_mbus_pixelcode code;
} mbus_formats[] = {
{ Y8, V4L2_MBUS_FMT_Y8_1X8},
+ { Y10, V4L2_MBUS_FMT_Y10_1X10 },
+ { Y12, V4L2_MBUS_FMT_Y12_1X12 },
{ YUYV, V4L2_MBUS_FMT_YUYV8_1X16 },
{ UYVY, V4L2_MBUS_FMT_UYVY8_1X16 },
{ SBGGR8, V4L2_MBUS_FMT_SBGGR8_1X8 },
--
1.7.5.4
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
--
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
[PATCH 2/2] allow using autoconf 2.61+
Autoconf v2.61 seems to work just fine. Allow it. Signed-off-by: Michael Jones michael.jo...@matrix-vision.de --- configure.in |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.in b/configure.in index 3f4f35b..fd4c70c 100644 --- a/configure.in +++ b/configure.in @@ -1,4 +1,4 @@ -AC_PREREQ([2.65]) +AC_PREREQ([2.61]) AC_INIT([media-ctl], [0.0.1], [laurent.pinch...@ideasonboard.com]) AC_CONFIG_SRCDIR([src/main.c]) AC_CONFIG_AUX_DIR([config]) -- 1.7.5.4 MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner -- 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: RTL2831U driver updates
2011/6/21 Jan Hoogenraad jan-conceptro...@hoogenraad.net: and add the IR remote interface, based on the LIRC framework. It actually should yield little code, and mainly requires a) understanding of LIRC and b) comparing code tables to that the in-kernel code tables can be re-used. sorry for the noise , but i guess you mean rc-core not Lirc -- 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 0/2] media-ctl: minor changes
Hi Michael, On Tuesday 21 June 2011 09:39:15 Michael Jones wrote: Hi Laurent, These are a couple of commits that I have locally on top of your media-ctl head which I would like to see in your rep. Michael Jones (2): add Y10, Y12 formats try using autoconf 2.61 configure.in |2 +- src/main.c |2 ++ 2 files changed, 3 insertions(+), 1 deletions(-) Thanks for the patches. Applied and pushed. -- Regards, Laurent Pinchart -- 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: RTL2831U driver updates
Can I put this somewhere in the git archive at the linuxtv site, so that we can share and have version control ? Maxim Levitsky wrote: On Tue, 2011-06-21 at 01:22 +0300, Antti Palosaari wrote: It is Maxim who have been hacking with RTL2832/RTL2832U lately. But I think he have given up since no noise anymore. I have taken now it again up to my desk and have been hacking two days now. Currently I am working with RTL2830 demod driver, I started it from scratch. Take sniffs, make scripts to generate code from USB traffic, copy pasted that to driver skeleton and now I have picture. Just implement all one-by-one until ready :-) I think I will implement it as minimum possible, no any signal statistic counters - lets add those later if someone wants to do that. USB-bridge part is rather OK as I did earlier and it is working with RTL2831U and RTL2832U at least. No remote support yet. I hope someone else would make missing driver for RTL2832U demod still... Fine! In about month, after exams, I hope I will work on this to finish at least RTL2832/FC0012. For reference, this is the code I did so far. Best regards, Maxim Levitsky -- Jan Hoogenraad Hoogenraad Interface Services Postbus 2717 3500 GS Utrecht -- 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 3/3] s5p-tv: add drivers for TV on Samsung S5P platform
Hi Hans,
On Thursday, June 09, 2011 18:18:47 Tomasz Stanislawski wrote:
Hans Verkuil wrote:
On Wednesday, June 08, 2011 14:03:31 Tomasz Stanislawski wrote:
And now the mixer review...
I'll separate patches. What is the proposed order of drivers?
HDMI+HDMIPHY, SDO, MIXER. That's easiest to review.
Add drivers for TV outputs on Samsung platforms from S5P family.
- HDMIPHY - auxiliary I2C driver need by TV driver
- HDMI- generation and control of streaming by HDMI output
- SDO - streaming analog TV by Composite connector
- MIXER - merging images from three layers and passing result to the output
Interface:
- 3 video nodes with output queues
- support for multi plane API
- each nodes has up to 2 outputs (HDMI and SDO)
- outputs are controlled by S_STD and S_DV_PRESET ioctls
Drivers are using:
- v4l2 framework
- videobuf2
- videobuf2-dma-contig as memory allocator
- runtime PM
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Reviewed-by: Marek Szyprowski m.szyprow...@samsung.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
[snip]
+static int mxr_g_fmt(struct file *file, void *priv,
+struct v4l2_format *f)
+{
+ struct mxr_layer *layer = video_drvdata(file);
+
+ mxr_dbg(layer-mdev, %s:%d\n, __func__, __LINE__);
+
+ f-fmt.pix.width = layer-geo.src.full_width;
+ f-fmt.pix.height= layer-geo.src.full_height;
+ f-fmt.pix.field = V4L2_FIELD_NONE;
+ f-fmt.pix.pixelformat = layer-fmt-fourcc;
Colorspace is not set. The subdev drivers should set the colorspace and that
should be passed in here.
Which one should be used for formats in vp_layer and grp_layer?
Should I use V4L2_COLORSPACE_SRGB for RGB formats,
and V4L2_COLORSPACE_JPEG for NV12(T) formats?
The Mixer possesses no knowledge how pixel values are mapped to output
color.
This is controlled by output driver (HDMI or SDO).
+
+ return 0;
+}
+
+static inline struct mxr_crop *choose_crop_by_type(struct mxr_geometry *geo,
+ enum v4l2_buf_type type)
+{
+ switch (type) {
+ case V4L2_BUF_TYPE_VIDEO_OUTPUT:
+ case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
+ return geo-dst;
+ case V4L2_BUF_TYPE_VIDEO_OVERLAY:
+ return geo-src;
Hmm, this is the only place where I see overlay. It's not set in QUERYCAP
either.
And I suspect this is supposed to be OUTPUT_OVERLAY anyway since OVERLAY is for
capture.
Usage of OVERLAY is workaround for a lack of S_COMPOSE. This is
described in RFC.
Ah, now I understand.
I don't like this hack to be honest. Can't this be done differently? I
understand
from the RFC that the reason is that widths have to be a multiple of 64. So why
not use the bytesperline field in v4l2_pix_format(_mplane)? So you can set the
width to e.g. 1440 and bytesperline to 1472. That does very simple cropping, but
it seems that this is sufficient for your immediate needs.
I do not like idea of using bytesperline for NV12T format.
The data ordering in NV12T is very different from both single and
mutiplanar formats.
There is no good definition of bytesperline for this format.
One could try to use analogy of this field based on NV12 format, that
bytesperline is equal
to length in bytes of a single luminance line.
However there is no control over offsets controlled by {left/top} in
cropping API.
In my opinion, using bytesperline for a cropping purpose is also a hack.
Cropping on an unused overlay buffer provides at least good and explicit
control over cropping.
I think it is a good temporary solution until S_SELECTION emerge.
+ default:
+ return NULL;
+ }
+}
+
[snip]
+
+static int mxr_g_dv_preset(struct file *file, void *fh,
+ struct v4l2_dv_preset *preset)
+{
+ struct mxr_layer *layer = video_drvdata(file);
+ struct mxr_device *mdev = layer-mdev;
+ int ret;
+
+ /* lock protects from changing sd_out */
Needs a check against n_output as well.
Probably I use query_dv_preset wrong.
You mean g_dv_preset, right?
Exactly, but v4l2_subdev misses g_dv_preset callback.
Should I add it like in g_tvnorms case?
Best regards,
Tomasz Stanislawski
--
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] vtunerc - virtual DVB device driver
On 06/21/2011 03:35 AM, Mauro Carvalho Chehab wrote: Em 20-06-2011 18:31, HoP escreveu: 2011/6/20 Mauro Carvalho Chehab mche...@redhat.com: Em 20-06-2011 17:24, HoP escreveu: 2011/6/20 Devin Heitmueller dheitmuel...@kernellabs.com: On Mon, Jun 20, 2011 at 3:56 PM, HoP jpetr...@gmail.com wrote: Do you think it is really serious enough reason to prevent of having such virtualization driver in the kernel? Let check my situation and tell me how I should continue (TBH, I already thought that driver can be accepted, but my dumb brain thought because of non quality code/design or so. It was really big surprise which reason was used aginst it): Yes, this is entirely a political issue and not a technical one. Political? So we can declare that politics win (again) technicians. Sad. This is not a political issue. It is a licensing issue. If you want to use someone's else code, you need to accept the licensing terms that the developers are giving you, by either paying the price for the code usage (on closed source licensing models), or by accepting the license when using an open-sourced code. Preserving the open-source eco-system is something that everyone developing open source expect: basically, you're free to do whatever you want, but if you're using a code written by an open-source developer, the expected behaviour that GPL asks (and that the developer wants, when he opted for GPL) is that you should return back to the community with any changes you did, including derivative work. This is an essential rule of working with GPL. If you're not happy with that, that's fine. You can implement another stack that is not GPL-licensed. Mauro, you totally misunderstood me. If you see on my first post in that thread I was sending full GPL-ed driver to the mailinglist. You misunderstood me. Something that exposes the kernel interface to for an userspace client driver to implement DVB is not a driver, it is a wrapper. The real driver will be in userspace, using the DVB stack, and can even be closed source. Some developers already tried to do things like that and sell the userspace code. Such code submission were nacked. There is even one case where the kernelspace code were dropped due to that (and later, replaced by an opensource driver). We don't want to go on this way again. Mauro and Devin, I think you're missing the point. This is not about creating drivers in userspace. This is not about open or closed source. The vtuner interface, as implemented for the Dreambox, is used to access remote tuners: Put x tuners into y boxes and access them from another box as if they were local. It's used in conjunction with further software to receive the transport stream over a network connection. Honza's code does the same thing. You don't need it in order to create closed source drivers. You can already create closed kernel drivers now. Also, you can create tuner drivers in userspace using the i2c-dev interface. If you like to connect a userspace driver to a DVB API device node, you can distribute a small (open or closed) wrapper with it. So what are you arguing about? Everything you're feared of can already be done since virtually forever. If you're feared of exposing kernel interfaces to userspace, then I think your only option is to remove the whole userspace. You might want to remove i2c-dev and the loadable module interface first. Regarding the code, Honza, I think the interface is neither clean nor generic enough to be included in the kernel. It doesn't make much sense to stay compatible to the interface used by the Dreambox. This interface evolved from very old versions of the DVB API and therefore carries way too much cruft and hacks for a shiny new interface. As a side note: Your ioctl constants already differ from the original vtuner code. IMO, at least these steps need to be taken: - Remove unused code. You already mentioned it, but it really should be removed before submitting code, because it makes review much harder. - Remove redefined structs and constants. - Drop support for anything older than S2API. - Define a way to use an existing demux instead of registering a new software demux. On hardware that supports it, an input channel should be allocated for each vtuner, in order to use the hardware's filtering and decoding capabilities. - Drop VTUNER_SET_NAME, VTUNER_SET_HAS_OUTPUTS, VTUNER_SET_MODES, VTUNER_SET_TYPE and VTUNER_SET_NUM_MODES. They are all either specific to the Dreambox or already obsoleted by S2API commands or should be implemented as new S2API commands. Regards, Andreas -- 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 3/3] s5p-tv: add drivers for TV on Samsung S5P platform
On Tuesday, June 21, 2011 12:55:57 Tomasz Stanislawski wrote:
Hi Hans,
On Thursday, June 09, 2011 18:18:47 Tomasz Stanislawski wrote:
Hans Verkuil wrote:
On Wednesday, June 08, 2011 14:03:31 Tomasz Stanislawski wrote:
And now the mixer review...
I'll separate patches. What is the proposed order of drivers?
HDMI+HDMIPHY, SDO, MIXER. That's easiest to review.
Add drivers for TV outputs on Samsung platforms from S5P family.
- HDMIPHY - auxiliary I2C driver need by TV driver
- HDMI- generation and control of streaming by HDMI output
- SDO - streaming analog TV by Composite connector
- MIXER - merging images from three layers and passing result to the
output
Interface:
- 3 video nodes with output queues
- support for multi plane API
- each nodes has up to 2 outputs (HDMI and SDO)
- outputs are controlled by S_STD and S_DV_PRESET ioctls
Drivers are using:
- v4l2 framework
- videobuf2
- videobuf2-dma-contig as memory allocator
- runtime PM
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Reviewed-by: Marek Szyprowski m.szyprow...@samsung.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
[snip]
+static int mxr_g_fmt(struct file *file, void *priv,
+ struct v4l2_format *f)
+{
+struct mxr_layer *layer = video_drvdata(file);
+
+mxr_dbg(layer-mdev, %s:%d\n, __func__, __LINE__);
+
+f-fmt.pix.width= layer-geo.src.full_width;
+f-fmt.pix.height = layer-geo.src.full_height;
+f-fmt.pix.field= V4L2_FIELD_NONE;
+f-fmt.pix.pixelformat = layer-fmt-fourcc;
Colorspace is not set. The subdev drivers should set the colorspace and
that
should be passed in here.
Which one should be used for formats in vp_layer and grp_layer?
Should I use V4L2_COLORSPACE_SRGB for RGB formats,
and V4L2_COLORSPACE_JPEG for NV12(T) formats?
The Mixer possesses no knowledge how pixel values are mapped to output
color.
This is controlled by output driver (HDMI or SDO).
Good question, actually.
The spec says:
'This information supplements the pixelformat and must be set by the driver,
see the section called “Colorspaces”.'
But does it make sense that the driver sets it for output? I think this should
be set by the application in that case. The driver sets it for input, the
application sets it for output.
G_FMT should return some sensible default based on the pixelformat if the
application left it to 0.
I think you should write up a small RFC proposing this change in the spec.
+
+return 0;
+}
+
+static inline struct mxr_crop *choose_crop_by_type(struct mxr_geometry
*geo,
+enum v4l2_buf_type type)
+{
+switch (type) {
+case V4L2_BUF_TYPE_VIDEO_OUTPUT:
+case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
+return geo-dst;
+case V4L2_BUF_TYPE_VIDEO_OVERLAY:
+return geo-src;
Hmm, this is the only place where I see overlay. It's not set in
QUERYCAP either.
And I suspect this is supposed to be OUTPUT_OVERLAY anyway since OVERLAY
is for
capture.
Usage of OVERLAY is workaround for a lack of S_COMPOSE. This is
described in RFC.
Ah, now I understand.
I don't like this hack to be honest. Can't this be done differently? I
understand
from the RFC that the reason is that widths have to be a multiple of 64.
So why
not use the bytesperline field in v4l2_pix_format(_mplane)? So you can set
the
width to e.g. 1440 and bytesperline to 1472. That does very simple
cropping, but
it seems that this is sufficient for your immediate needs.
I do not like idea of using bytesperline for NV12T format.
The data ordering in NV12T is very different from both single and
mutiplanar formats.
NV12T, I missed that fact.
There is no good definition of bytesperline for this format.
One could try to use analogy of this field based on NV12 format, that
bytesperline is equal
to length in bytes of a single luminance line.
However there is no control over offsets controlled by {left/top} in
cropping API.
In my opinion, using bytesperline for a cropping purpose is also a hack.
Cropping on an unused overlay buffer provides at least good and explicit
control over cropping.
I think it is a good temporary solution until S_SELECTION emerge.
Hmm, this needs to be documented carefully and I think the driver needs to be
marked EXPERIMENTAL in Kconfig. This makes it clear that the API will change.
+default:
+return NULL;
+}
+}
+
[snip]
+
+static int mxr_g_dv_preset(struct file *file, void *fh,
+struct v4l2_dv_preset *preset)
+{
+struct mxr_layer
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/21 Mauro Carvalho Chehab mche...@redhat.com: Em 20-06-2011 18:31, HoP escreveu: 2011/6/20 Mauro Carvalho Chehab mche...@redhat.com: Em 20-06-2011 17:24, HoP escreveu: 2011/6/20 Devin Heitmueller dheitmuel...@kernellabs.com: On Mon, Jun 20, 2011 at 3:56 PM, HoP jpetr...@gmail.com wrote: Do you think it is really serious enough reason to prevent of having such virtualization driver in the kernel? Let check my situation and tell me how I should continue (TBH, I already thought that driver can be accepted, but my dumb brain thought because of non quality code/design or so. It was really big surprise which reason was used aginst it): Yes, this is entirely a political issue and not a technical one. Political? So we can declare that politics win (again) technicians. Sad. This is not a political issue. It is a licensing issue. If you want to use someone's else code, you need to accept the licensing terms that the developers are giving you, by either paying the price for the code usage (on closed source licensing models), or by accepting the license when using an open-sourced code. Preserving the open-source eco-system is something that everyone developing open source expect: basically, you're free to do whatever you want, but if you're using a code written by an open-source developer, the expected behaviour that GPL asks (and that the developer wants, when he opted for GPL) is that you should return back to the community with any changes you did, including derivative work. This is an essential rule of working with GPL. If you're not happy with that, that's fine. You can implement another stack that is not GPL-licensed. Mauro, you totally misunderstood me. If you see on my first post in that thread I was sending full GPL-ed driver to the mailinglist. You misunderstood me. Something that exposes the kernel interface to for an userspace client driver to implement DVB is not a driver, it is a wrapper. The real driver will be in userspace, using the DVB stack, and can even be closed source. Some developers already tried to do things like that and sell the userspace code. Such code submission were nacked. There is even one case where the kernelspace code were dropped due to that (and later, replaced by an opensource driver). No, you are again wrong, sorry. If you ever tried to understand my small schema and description, you would find that REAL drivers remeains in kernel. May be you understand what I want from attached picture. You can see that the driver acts as bridge (ok, you like wording wrapper so) to distribute remote driver functionality down to the client and back. /Honza attachment: vtuner-small-picture.png
Re: [RFC] vtunerc - virtual DVB device driver
Em 21-06-2011 08:04, Andreas Oberritter escreveu: On 06/21/2011 03:35 AM, Mauro Carvalho Chehab wrote: Em 20-06-2011 18:31, HoP escreveu: 2011/6/20 Mauro Carvalho Chehab mche...@redhat.com: Em 20-06-2011 17:24, HoP escreveu: 2011/6/20 Devin Heitmueller dheitmuel...@kernellabs.com: On Mon, Jun 20, 2011 at 3:56 PM, HoP jpetr...@gmail.com wrote: Do you think it is really serious enough reason to prevent of having such virtualization driver in the kernel? Let check my situation and tell me how I should continue (TBH, I already thought that driver can be accepted, but my dumb brain thought because of non quality code/design or so. It was really big surprise which reason was used aginst it): Yes, this is entirely a political issue and not a technical one. Political? So we can declare that politics win (again) technicians. Sad. This is not a political issue. It is a licensing issue. If you want to use someone's else code, you need to accept the licensing terms that the developers are giving you, by either paying the price for the code usage (on closed source licensing models), or by accepting the license when using an open-sourced code. Preserving the open-source eco-system is something that everyone developing open source expect: basically, you're free to do whatever you want, but if you're using a code written by an open-source developer, the expected behaviour that GPL asks (and that the developer wants, when he opted for GPL) is that you should return back to the community with any changes you did, including derivative work. This is an essential rule of working with GPL. If you're not happy with that, that's fine. You can implement another stack that is not GPL-licensed. Mauro, you totally misunderstood me. If you see on my first post in that thread I was sending full GPL-ed driver to the mailinglist. You misunderstood me. Something that exposes the kernel interface to for an userspace client driver to implement DVB is not a driver, it is a wrapper. The real driver will be in userspace, using the DVB stack, and can even be closed source. Some developers already tried to do things like that and sell the userspace code. Such code submission were nacked. There is even one case where the kernelspace code were dropped due to that (and later, replaced by an opensource driver). We don't want to go on this way again. Mauro and Devin, I think you're missing the point. This is not about creating drivers in userspace. This is not about open or closed source. The vtuner interface, as implemented for the Dreambox, is used to access remote tuners: Put x tuners into y boxes and access them from another box as if they were local. It's used in conjunction with further software to receive the transport stream over a network connection. Honza's code does the same thing. You don't need it in order to create closed source drivers. You can already create closed kernel drivers now. Also, you can create tuner drivers in userspace using the i2c-dev interface. If you like to connect a userspace driver to a DVB API device node, you can distribute a small (open or closed) wrapper with it. So what are you arguing about? Everything you're feared of can already be done since virtually forever. Yes, but we don't need to review/maintain a kernel driver meant to be used by closed source applications, and, if they're using a GPL'd code inside a closed source application, they can be sued. I didn't review the patchset, but, from the description, I understood that it were developed to use some Dreambox-specific closed source applications. With such requirement, for me it is just a wrapper to some closed source application. That's said, I'm not against a driver that allows using a DVB kernel driver by a DVB open source application either inside a virtual machine or on a remote machine. This seems useful for me. So, if the code could be turned into it, I'll review and consider for its inclusion upstream. For that to happen, it should not try to use any Dreambox specific application or protocol, but to just use the standard DVBv5 API, as you've pointed. If you're feared of exposing kernel interfaces to userspace, then I think your only option is to remove the whole userspace. You might want to remove i2c-dev and the loadable module interface first. Regarding the code, Honza, I think the interface is neither clean nor generic enough to be included in the kernel. It doesn't make much sense to stay compatible to the interface used by the Dreambox. This interface evolved from very old versions of the DVB API and therefore carries way too much cruft and hacks for a shiny new interface. As a side note: Your ioctl constants already differ from the original vtuner code. IMO, at least these steps need to be taken: - Remove unused code. You already mentioned it, but it really should be removed before submitting code, because it makes review much harder. -
Re: [RFC] vtunerc - virtual DVB device driver
On 06/21/2011 02:05 PM, Mauro Carvalho Chehab wrote: Em 21-06-2011 08:04, Andreas Oberritter escreveu: On 06/21/2011 03:35 AM, Mauro Carvalho Chehab wrote: Em 20-06-2011 18:31, HoP escreveu: 2011/6/20 Mauro Carvalho Chehab mche...@redhat.com: Em 20-06-2011 17:24, HoP escreveu: 2011/6/20 Devin Heitmueller dheitmuel...@kernellabs.com: On Mon, Jun 20, 2011 at 3:56 PM, HoP jpetr...@gmail.com wrote: Do you think it is really serious enough reason to prevent of having such virtualization driver in the kernel? Let check my situation and tell me how I should continue (TBH, I already thought that driver can be accepted, but my dumb brain thought because of non quality code/design or so. It was really big surprise which reason was used aginst it): Yes, this is entirely a political issue and not a technical one. Political? So we can declare that politics win (again) technicians. Sad. This is not a political issue. It is a licensing issue. If you want to use someone's else code, you need to accept the licensing terms that the developers are giving you, by either paying the price for the code usage (on closed source licensing models), or by accepting the license when using an open-sourced code. Preserving the open-source eco-system is something that everyone developing open source expect: basically, you're free to do whatever you want, but if you're using a code written by an open-source developer, the expected behaviour that GPL asks (and that the developer wants, when he opted for GPL) is that you should return back to the community with any changes you did, including derivative work. This is an essential rule of working with GPL. If you're not happy with that, that's fine. You can implement another stack that is not GPL-licensed. Mauro, you totally misunderstood me. If you see on my first post in that thread I was sending full GPL-ed driver to the mailinglist. You misunderstood me. Something that exposes the kernel interface to for an userspace client driver to implement DVB is not a driver, it is a wrapper. The real driver will be in userspace, using the DVB stack, and can even be closed source. Some developers already tried to do things like that and sell the userspace code. Such code submission were nacked. There is even one case where the kernelspace code were dropped due to that (and later, replaced by an opensource driver). We don't want to go on this way again. Mauro and Devin, I think you're missing the point. This is not about creating drivers in userspace. This is not about open or closed source. The vtuner interface, as implemented for the Dreambox, is used to access remote tuners: Put x tuners into y boxes and access them from another box as if they were local. It's used in conjunction with further software to receive the transport stream over a network connection. Honza's code does the same thing. You don't need it in order to create closed source drivers. You can already create closed kernel drivers now. Also, you can create tuner drivers in userspace using the i2c-dev interface. If you like to connect a userspace driver to a DVB API device node, you can distribute a small (open or closed) wrapper with it. So what are you arguing about? Everything you're feared of can already be done since virtually forever. Yes, but we don't need to review/maintain a kernel driver meant to be used by closed source applications *Not that it would apply to this case*, but disallowing closed source applications in userspace is ridiculous. And why should you reject a possibly nice interface just because no open source application using it has already been written? and, if they're using a GPL'd code inside a closed source application, they can be sued. I didn't review the patchset, but, from the description, I understood that it were developed to use some Dreambox-specific closed source applications. With such requirement, for me it is just a wrapper to some closed source application. I see. That's where you're wrong. Neither does it depend on any closed application (Honza even included the link to the source code of the application: https://code.google.com/p/dreamtuner/), nor is this application specific to the Dreambox. The Dreambox is just the origin of the vtuner API. Btw.: Honza repeatedly stated that he's using his code with VDR, which in other words means that he's not using a Dreambox. That's said, I'm not against a driver that allows using a DVB kernel driver by a DVB open source application either inside a virtual machine or on a remote machine. This seems useful for me. So, if the code could be turned into it, I'll review and consider for its inclusion upstream. You mean, if the code could be turned into what it already is? For that to happen, it should not try to use any Dreambox specific application or protocol, but to just use the standard DVBv5 API, as you've pointed. The DVB API v5 (as of now) is a
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/21 Mauro Carvalho Chehab mche...@redhat.com: Em 21-06-2011 08:04, Andreas Oberritter escreveu: On 06/21/2011 03:35 AM, Mauro Carvalho Chehab wrote: Em 20-06-2011 18:31, HoP escreveu: 2011/6/20 Mauro Carvalho Chehab mche...@redhat.com: Em 20-06-2011 17:24, HoP escreveu: 2011/6/20 Devin Heitmueller dheitmuel...@kernellabs.com: On Mon, Jun 20, 2011 at 3:56 PM, HoP jpetr...@gmail.com wrote: Do you think it is really serious enough reason to prevent of having such virtualization driver in the kernel? Let check my situation and tell me how I should continue (TBH, I already thought that driver can be accepted, but my dumb brain thought because of non quality code/design or so. It was really big surprise which reason was used aginst it): Yes, this is entirely a political issue and not a technical one. Political? So we can declare that politics win (again) technicians. Sad. This is not a political issue. It is a licensing issue. If you want to use someone's else code, you need to accept the licensing terms that the developers are giving you, by either paying the price for the code usage (on closed source licensing models), or by accepting the license when using an open-sourced code. Preserving the open-source eco-system is something that everyone developing open source expect: basically, you're free to do whatever you want, but if you're using a code written by an open-source developer, the expected behaviour that GPL asks (and that the developer wants, when he opted for GPL) is that you should return back to the community with any changes you did, including derivative work. This is an essential rule of working with GPL. If you're not happy with that, that's fine. You can implement another stack that is not GPL-licensed. Mauro, you totally misunderstood me. If you see on my first post in that thread I was sending full GPL-ed driver to the mailinglist. You misunderstood me. Something that exposes the kernel interface to for an userspace client driver to implement DVB is not a driver, it is a wrapper. The real driver will be in userspace, using the DVB stack, and can even be closed source. Some developers already tried to do things like that and sell the userspace code. Such code submission were nacked. There is even one case where the kernelspace code were dropped due to that (and later, replaced by an opensource driver). We don't want to go on this way again. Mauro and Devin, I think you're missing the point. This is not about creating drivers in userspace. This is not about open or closed source. The vtuner interface, as implemented for the Dreambox, is used to access remote tuners: Put x tuners into y boxes and access them from another box as if they were local. It's used in conjunction with further software to receive the transport stream over a network connection. Honza's code does the same thing. You don't need it in order to create closed source drivers. You can already create closed kernel drivers now. Also, you can create tuner drivers in userspace using the i2c-dev interface. If you like to connect a userspace driver to a DVB API device node, you can distribute a small (open or closed) wrapper with it. So what are you arguing about? Everything you're feared of can already be done since virtually forever. Yes, but we don't need to review/maintain a kernel driver meant to be used by closed source applications, and, if they're using a GPL'd code inside a closed source application, they can be sued. Well, seems you are trying to argue using wrong arguments. One more again: If you follow my picture - all on the path, INCLUDING userland application, is GPL code. If you think about Enigma, it is GPLed also, at least version 1. But my driver is not for dreamboxes! They have similar implementation already included there. My intention was different: to allow same thing like is possible with dreamboxes, on normal linux PC desktop. Using any other userland DVB application, like VDR or MythTV or vlc. Got my point? I have nothing to do with any closed source or even binary blobs! I want DVB adapter distribution across network, nothing more. Everything is clear, from GPL point of view. I didn't review the patchset, but, from the description, I understood that it were developed to use some Dreambox-specific closed source applications. With such requirement, for me it is just a wrapper to some closed source application. I understand that my English can be not crystal clear, so you missed inside my description. But I must say it again - my code has zero connection with dreamboxes. Of course other then borrowing theirs sharing possibility and reusing same network daemons (again fully GPLed!) for it. That's said, I'm not against a driver that allows using a DVB kernel driver by a DVB open source application either inside a virtual machine or on a remote machine. This seems useful for me. So, if the code could be turned
Re: [RFC] vtunerc - virtual DVB device driver
I hope this driver will be included if it can be useful for some and if it follows the GPL rules. But really, +1 to Sebastien's comment - this project is a frustrating one it seems. And at the point where I am, I would rather pay for a working driver for a S2 + CI card, instead of trying to debug existing drivers for which the maintainers are virtually non existent. -- Issa -- 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] vtunerc - virtual DVB device driver
On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter o...@linuxtv.org wrote: Mauro and Devin, I think you're missing the point. This is not about creating drivers in userspace. This is not about open or closed source. The vtuner interface, as implemented for the Dreambox, is used to access remote tuners: Put x tuners into y boxes and access them from another box as if they were local. It's used in conjunction with further software to receive the transport stream over a network connection. Honza's code does the same thing. I'm not missing the point at all. I realize exactly what Honza is trying to accomplish (and from a purely technical standpoint, it's not a bad approach) - but I'm talking about the effects of such a driver being introduced which changes the kernel/userland licensing boundary and has very real implications with how the in-kernel code is accessed. You don't need it in order to create closed source drivers. You can already create closed kernel drivers now. Also, you can create tuner drivers in userspace using the i2c-dev interface. If you like to connect a userspace driver to a DVB API device node, you can distribute a small (open or closed) wrapper with it. So what are you arguing about? Everything you're feared of can already be done since virtually forever. I disagree. There is currently no API which allows applications to issue tuning requests into the DVB core, and have those requests proxied back out to userland where an application can then use i2c-dev to tune the actual device. Meaning if somebody wants to write a closed source userland application which controls the tuner, he/she can do that (while not conforming to the DVB API). But if if he wants to reuse the GPL licensed DVB core, he has to replace the entire DVB core. The introduction of this patch makes it trivial for a third party to provide closed-source userland support for tuners while reusing all the existing GPL driver code that makes up the framework. I used to work for a vendor that makes tuners, and they do a bunch of Linux work. And that work has resulted in a bunch of open source drivers. I can tell you though that *every* conversation I've had regarding a new driver goes something like this: === Devin, we need to support tuner X under Linux. Great! I'll be happy to write a new GPL driver for the tuner/demodulator/whatever for that device But to save time/money, we just want to reuse the Windows driver code (or reference code from the vendor). Ok. Well, what is the licensing for that code? Is it GPL compatible? Not currently. So can we just make our driver closed source? Well, you can't reuse any of the existing DVB core functionality or any of the other GPL drivers (tuners, bridges, demods), so you would have rewrite all that from scratch. Oh, that would be a ton of work. Can we maybe write some userland stuff that controls the demodulator which we can keep closed source? Since it's not in the kernel, the GPL won't apply. Well, you can't really do that because there is no way for the DVB core to call back out to userland when the application makes the tuning request to the DVB core. Oh, ok then. I guess we'll have to talk to the vendor and get them to give us the reference driver code under the GPL. === I can tell you without a doubt that if this driver were present in the kernel, that going forward that vendor would have *zero* interest in doing any GPL driver work. Why would they? Why give away the code which could potentially help their competitors if they can keep it safe and protected while still being able to reuse everybody else's contributions? Companies don't contribute GPL code out of good will. They do it because they are compelled to by licenses or because there is no economically viable alternative. Mauro, ultimately it is your decision as the maintainer which drivers get accepted in to the kernel. I can tell you though that this will be a very bad thing for the driver ecosystem as a whole - it will essentially make it trivial for vendors (some of which who are doing GPL work now) to provide solutions that reuse the GPL'd DVB core without having to make any of their stuff open source. Anyway, I said in my last email that would be my last email on the topic. I guess I lied. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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] vtunerc - virtual DVB device driver
On 06/21/2011 03:44 PM, Devin Heitmueller wrote: On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter o...@linuxtv.org wrote: Mauro and Devin, I think you're missing the point. This is not about creating drivers in userspace. This is not about open or closed source. The vtuner interface, as implemented for the Dreambox, is used to access remote tuners: Put x tuners into y boxes and access them from another box as if they were local. It's used in conjunction with further software to receive the transport stream over a network connection. Honza's code does the same thing. I'm not missing the point at all. I realize exactly what Honza is trying to accomplish (and from a purely technical standpoint, it's not a bad approach) - but I'm talking about the effects of such a driver being introduced which changes the kernel/userland licensing boundary and has very real implications with how the in-kernel code is accessed. You don't need it in order to create closed source drivers. You can already create closed kernel drivers now. Also, you can create tuner drivers in userspace using the i2c-dev interface. If you like to connect a userspace driver to a DVB API device node, you can distribute a small (open or closed) wrapper with it. So what are you arguing about? Everything you're feared of can already be done since virtually forever. I disagree. There is currently no API which allows applications to issue tuning requests into the DVB core, and have those requests proxied back out to userland where an application can then use i2c-dev to tune the actual device. Meaning if somebody wants to write a closed source userland application which controls the tuner, he/she can do that (while not conforming to the DVB API). But if if he wants to reuse the GPL licensed DVB core, he has to replace the entire DVB core. The introduction of this patch makes it trivial for a third party to provide closed-source userland support for tuners while reusing all the existing GPL driver code that makes up the framework. I used to work for a vendor that makes tuners, and they do a bunch of Linux work. And that work has resulted in a bunch of open source drivers. I can tell you though that *every* conversation I've had regarding a new driver goes something like this: === Devin, we need to support tuner X under Linux. Great! I'll be happy to write a new GPL driver for the tuner/demodulator/whatever for that device But to save time/money, we just want to reuse the Windows driver code (or reference code from the vendor). Ok. Well, what is the licensing for that code? Is it GPL compatible? Not currently. So can we just make our driver closed source? Well, you can't reuse any of the existing DVB core functionality or any of the other GPL drivers (tuners, bridges, demods), so you would have rewrite all that from scratch. Oh, that would be a ton of work. Can we maybe write some userland stuff that controls the demodulator which we can keep closed source? Since it's not in the kernel, the GPL won't apply. Well, you can't really do that because there is no way for the DVB core to call back out to userland when the application makes the tuning request to the DVB core. Oh, ok then. I guess we'll have to talk to the vendor and get them to give us the reference driver code under the GPL. === I can tell you without a doubt that if this driver were present in the kernel, that going forward that vendor would have *zero* interest in doing any GPL driver work. Why would they? Why give away the code which could potentially help their competitors if they can keep it safe and protected while still being able to reuse everybody else's contributions? Companies don't contribute GPL code out of good will. They do it because they are compelled to by licenses or because there is no economically viable alternative. Mauro, ultimately it is your decision as the maintainer which drivers get accepted in to the kernel. I can tell you though that this will be a very bad thing for the driver ecosystem as a whole - it will essentially make it trivial for vendors (some of which who are doing GPL work now) to provide solutions that reuse the GPL'd DVB core without having to make any of their stuff open source. Anyway, I said in my last email that would be my last email on the topic. I guess I lied. Yes, and you did lie to your vendor, too, as you did not mention the possibilities to create 1.) closed source modules derived from existing vendor drivers while still being able to use other drivers (c.f. EXPORT_SYMBOL vs. EXPORT_SYMBOL_GPL). 2.) a simple wrapper that calls userspace, therefore not having to open up any secrets at all. Of course it's nice that you could trick that vendor into publishing code under GPL terms. And while everyone appreciates it, I would also appreciate keeping politics off the table. If the proposed interface results in closed
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/21 Andreas Oberritter o...@linuxtv.org: Yes, and you did lie to your vendor, too, as you did not mention the possibilities to create I don't know if this is a language barrier issue, but calling someone a liar (let alone in an open forum) is a pretty offensive thing to do. In fact, such discussions did come up. However I simply didn't mention them here in the previous email in an attempt consolidate one hour conversations into nine sentences in an attempt at brevity. 1.) closed source modules derived from existing vendor drivers while still being able to use other drivers (c.f. EXPORT_SYMBOL vs. EXPORT_SYMBOL_GPL). This definitely enters a grey area from a legal standpoint. Depending on who you talk to, using such symbols may or may not violate the GPL, depending on what lawyer you talk to. This all falls back to the notion of whether non-GPL loadable modules violate the GPL, for which even today there is considerable debate within the kernel community. Smart companies are generally risk-averse, and recognize that it's usually not worth the risk of being sued by doing something that may or may not violate a license. 2.) a simple wrapper that calls userspace, therefore not having to open up any secrets at all. Like the above, this raises all sorts of issues involving the definition of derivative work. Again, we're going around in circles here. This issue has been beaten to death both in the linux dvb mailing lists as well as in the lkml in general. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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] vtunerc - virtual DVB device driver
Devin Heitmueller dheitmuel...@kernellabs.com writes: The introduction of this patch makes it trivial for a third party to provide closed-source userland support for tuners while reusing all the existing GPL driver code that makes up the framework. Wouldn't it be just as trivial to bundle the closed-source tuner support with this patch or a similar GPL licensed driver? This doesn't change anything wrt closed source drivers. Bjørn -- 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] vtunerc - virtual DVB device driver
Em 21-06-2011 10:44, Devin Heitmueller escreveu: Mauro, ultimately it is your decision as the maintainer which drivers get accepted in to the kernel. I can tell you though that this will be a very bad thing for the driver ecosystem as a whole - it will essentially make it trivial for vendors (some of which who are doing GPL work now) to provide solutions that reuse the GPL'd DVB core without having to make any of their stuff open source. I was a little faster to answer to my previous emails. I'm not feeling well today due to a strong pain on my backbone. So, let me explain what would be ok, from my POV: A kernelspace driver that will follow DVBv5 API and talk with wit another device via the Kernel network stack, in order to access a remote Kernel board, or a kernel board at the physical machine, for virtual machines. That means that the dvb stack won't be proxied to an userspace application. Something like: Userspace app (like kaffeine, dvr, etc) - DVB net_tunnel driver - Kernel Network stack Kernel Network stack - DVB net_tunnel driver - DVB hardware In other words, the DVB net_tunnel driver will take care of using the network stack, implement Kernel namespaces, etc, in order to allow virtualizing a remote hardware, without needing any userspace driver for doing that (well, except, of course, for the standard network userspace applications for DNS solving, configuring IP routes, etc). Cheers, Mauro -- 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] vtunerc - virtual DVB device driver
Em 21-06-2011 11:56, Bjørn Mork escreveu: Devin Heitmueller dheitmuel...@kernellabs.com writes: The introduction of this patch makes it trivial for a third party to provide closed-source userland support for tuners while reusing all the existing GPL driver code that makes up the framework. Wouldn't it be just as trivial to bundle the closed-source tuner support with this patch or a similar GPL licensed driver? This doesn't change anything wrt closed source drivers. Yes, but adding some code into a GPL licensed code is derivative work, The end result is also covered by GPL (not only the kernelspace, but also the userspace counterpart). If some company is doing things like that and not providing the entire driver under GPL, if going to court, the judge will likely consider this as an explicitly attempt to violate the legal property of someone's else's copyright. Mauro -- 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] vtunerc - virtual DVB device driver
On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote: Em 21-06-2011 11:15, Andreas Oberritter escreveu: On 06/21/2011 03:44 PM, Devin Heitmueller wrote: On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter o...@linuxtv.org wrote: Mauro and Devin, I think you're missing the point. This is not about creating drivers in userspace. This is not about open or closed source. The vtuner interface, as implemented for the Dreambox, is used to access remote tuners: Put x tuners into y boxes and access them from another box as if they were local. It's used in conjunction with further software to receive the transport stream over a network connection. Honza's code does the same thing. I'm not missing the point at all. I realize exactly what Honza is trying to accomplish (and from a purely technical standpoint, it's not a bad approach) - but I'm talking about the effects of such a driver being introduced which changes the kernel/userland licensing boundary and has very real implications with how the in-kernel code is accessed. You don't need it in order to create closed source drivers. You can already create closed kernel drivers now. Also, you can create tuner drivers in userspace using the i2c-dev interface. If you like to connect a userspace driver to a DVB API device node, you can distribute a small (open or closed) wrapper with it. So what are you arguing about? Everything you're feared of can already be done since virtually forever. I disagree. There is currently no API which allows applications to issue tuning requests into the DVB core, and have those requests proxied back out to userland where an application can then use i2c-dev to tune the actual device. Meaning if somebody wants to write a closed source userland application which controls the tuner, he/she can do that (while not conforming to the DVB API). But if if he wants to reuse the GPL licensed DVB core, he has to replace the entire DVB core. The introduction of this patch makes it trivial for a third party to provide closed-source userland support for tuners while reusing all the existing GPL driver code that makes up the framework. I used to work for a vendor that makes tuners, and they do a bunch of Linux work. And that work has resulted in a bunch of open source drivers. I can tell you though that *every* conversation I've had regarding a new driver goes something like this: === Devin, we need to support tuner X under Linux. Great! I'll be happy to write a new GPL driver for the tuner/demodulator/whatever for that device But to save time/money, we just want to reuse the Windows driver code (or reference code from the vendor). Ok. Well, what is the licensing for that code? Is it GPL compatible? Not currently. So can we just make our driver closed source? Well, you can't reuse any of the existing DVB core functionality or any of the other GPL drivers (tuners, bridges, demods), so you would have rewrite all that from scratch. Oh, that would be a ton of work. Can we maybe write some userland stuff that controls the demodulator which we can keep closed source? Since it's not in the kernel, the GPL won't apply. Well, you can't really do that because there is no way for the DVB core to call back out to userland when the application makes the tuning request to the DVB core. Oh, ok then. I guess we'll have to talk to the vendor and get them to give us the reference driver code under the GPL. === I can tell you without a doubt that if this driver were present in the kernel, that going forward that vendor would have *zero* interest in doing any GPL driver work. Why would they? Why give away the code which could potentially help their competitors if they can keep it safe and protected while still being able to reuse everybody else's contributions? Companies don't contribute GPL code out of good will. They do it because they are compelled to by licenses or because there is no economically viable alternative. Mauro, ultimately it is your decision as the maintainer which drivers get accepted in to the kernel. I can tell you though that this will be a very bad thing for the driver ecosystem as a whole - it will essentially make it trivial for vendors (some of which who are doing GPL work now) to provide solutions that reuse the GPL'd DVB core without having to make any of their stuff open source. Anyway, I said in my last email that would be my last email on the topic. I guess I lied. Yes, and you did lie to your vendor, too, as you did not mention the possibilities to create 1.) closed source modules derived from existing vendor drivers while still being able to use other drivers (c.f. EXPORT_SYMBOL vs. EXPORT_SYMBOL_GPL). AFAIK, the legal issues on writing a closed source driver using EXPORT_SYMBOL are not proofed legally in any court. While EXPORT_SYMBOL_GPL explicitly adds a restriction, not using it doesn't necessarily mean that the symbol
Re: [em28xx] Support for TerraTec G3?
Em 08-06-2011 19:38, Chain von den Keiya escreveu:
Hello,
I hope this is the correct way to ask, so if it isn't, I am truly sorry.
c/c the linux-media mailing list, as other people may also have the same issue.
I have aquired a TerraTec G3 Video Grabber, USB-ID 0ccd:10a7. Now, I was
hoping that it would get detected by the em28xx driver - it contains an
em2860
chip - but it wasn't (as of 2.6.38). However, I could see that there are
quite
some models which look similar, so I tried out the whole card=xx range.
Didn't
help. So now the question is, can this be done? Or is it impossible and I
have
to scrap this nice little device? I would be willing to help - testing
drivers, opening the device up and identify chips, et cetera. Because I think
if it's not that hard, it won't hurt if Linux supports a few more devices.
(Actually, the G1 looks similar to this one again...)
The only thing I could find was:
http://linux.terratec.de/video_en.html - but no driver? I don't really
understand this. So, now I am at a loss, but not giving up yet. So please
help
me, either by pointing me into the right direction - or by enhancing the
driver to work with this card.
I pushed yesterday some patches for em2861 audio that may help to make your
device work. If the model is similar to Terratec Grabby, then perhaps all that
it is
needed is to add your device USB ID into the kernel driver.
Please test the enclosed patch.
em28xx: add support for TerraTec G3
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/video/em28xx/em28xx-cards.c
b/drivers/media/video/em28xx/em28xx-cards.c
index c892a1e..d6af828 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -1861,6 +1861,8 @@ struct usb_device_id em28xx_id_table[] = {
.driver_info = EM2860_BOARD_TERRATEC_AV350 },
{ USB_DEVICE(0x0ccd, 0x0096),
.driver_info = EM2860_BOARD_TERRATEC_GRABBY },
+ { USB_DEVICE(0x0ccd, 0x10a7),
+ .driver_info = EM2860_BOARD_TERRATEC_GRABBY },
{ USB_DEVICE(0x0fd9, 0x0033),
.driver_info = EM2860_BOARD_ELGATO_VIDEO_CAPTURE},
{ USB_DEVICE(0x185b, 0x2870),
--
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
[PATCH/RFC] fbdev: Add FOURCC-based format configuration API
This API will be used to support YUV frame buffer formats in a standard
way.
Last but not least, create a much needed fbdev API documentation and
document the format setting APIs.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
Documentation/fb/api.txt | 284 ++
include/linux/fb.h | 12 ++-
2 files changed, 294 insertions(+), 2 deletions(-)
create mode 100644 Documentation/fb/api.txt
A bit late, but here's a patch that implements an fbdev format configuration
API to support YUV formats. My next step is to implement a prototype in an
fbdev driver to make sure the API works well.
Thanks to Florian Tobias Schandinat for providing feedback on the initial RFC.
Comments are as usual more than welcome. If you feel like writing a couple of
lines of documentation, feel free to extend the API doc. That's much needed.
diff --git a/Documentation/fb/api.txt b/Documentation/fb/api.txt
new file mode 100644
index 000..d4cd6ec
--- /dev/null
+++ b/Documentation/fb/api.txt
@@ -0,0 +1,284 @@
+ The Frame Buffer Device API
+ ---
+
+Last revised: June 21, 2011
+
+
+0. Introduction
+---
+
+This document describes the frame buffer API used by applications to interact
+with frame buffer devices. In-kernel APIs between device drivers and the frame
+buffer core are not described.
+
+Due to a lack of documentation in the original frame buffer API, drivers
+behaviours differ in subtle (and not so subtle) ways. This document describes
+the recommended API implementation, but applications should be prepared to
+deal with different behaviours.
+
+
+1. Capabilities
+---
+
+Device and driver capabilities are reported in the fixed screen information
+capabilities field.
+
+struct fb_fix_screeninfo {
+ ...
+ __u16 capabilities; /* see FB_CAP_* */
+ ...
+};
+
+Application should use those capabilities to find out what features they can
+expect from the device and driver.
+
+- FB_CAP_FOURCC
+
+The driver supports the four character code (FOURCC) based format setting API.
+When supported, formats are configured using a FOURCC instead of manually
+specifying color components layout.
+
+
+2. Types and visuals
+
+
+Pixels are stored in memory in hardware-dependent formats. Applications need
+to be aware of the pixel storage format in order to write image data to the
+frame buffer memory in the format expected by the hardware.
+
+Formats are described by frame buffer types and visuals. Some visuals require
+additional information, which are stored in the variable screen information
+bits_per_pixel, grayscale, fourcc, red, green, blue and transp fields.
+
+The following types and visuals are supported.
+
+- FB_TYPE_PACKED_PIXELS
+
+Color components (usually RGB or YUV) are packed together into macropixels
+that are stored in a single plane. The exact color components layout is
+described in a visual-dependent way.
+
+Frame buffer visuals that don't use multiple color components per pixel
+(such as monochrome and pseudo-color visuals) are reported as packed frame
+buffer types, even though they don't stricly speaking pack color components
+into macropixels.
+
+- FB_TYPE_PLANES
+
+Color components are stored in separate planes. Planes are located
+contiguously in memory.
+
+- FB_VISUAL_MONO01
+
+Pixels are black or white and stored on one bit. A bit set to 1 represents a
+black pixel and a bit set to 0 a white pixel. Pixels are packed together in
+bytes with 8 pixels per byte.
+
+FB_VISUAL_MONO01 is used with FB_TYPE_PACKED_PIXELS only.
+
+- FB_VISUAL_MONO10
+
+Pixels are black or white and stored on one bit. A bit set to 1 represents a
+white pixel and a bit set to 0 a black pixel. Pixels are packed together in
+bytes with 8 pixels per byte.
+
+FB_VISUAL_MONO01 is used with FB_TYPE_PACKED_PIXELS only.
+
+- FB_VISUAL_TRUECOLOR
+
+Pixels are broken into red, green and blue components, and each component
+indexes a read-only lookup table for the corresponding value. Lookup tables
+are device-dependent, and provide linear or non-linear ramps.
+
+Each component is stored in memory according to the variable screen
+information red, green, blue and transp fields.
+
+- FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR
+
+Pixel values are encoded as indices into a colormap that stores red, green and
+blue components. The colormap is read-only for FB_VISUAL_STATIC_PSEUDOCOLOR
+and read-write for FB_VISUAL_PSEUDOCOLOR.
+
+Each pixel value is stored in the number of bits reported by the variable
+screen information bits_per_pixel field. Pixels are contiguous in memory.
+
+FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR are used with
+FB_TYPE_PACKED_PIXELS only.
+
+- FB_VISUAL_DIRECTCOLOR
+
+Pixels are broken into red, green and blue components, and each component
+indexes a programmable lookup table for the
RE: vb2: holding buffers until after start_streaming()
Hello, On Monday, June 20, 2011 5:49 PM Jonathan Corbet wrote: On Mon, 20 Jun 2011 07:30:11 +0200 Marek Szyprowski m.szyprow...@samsung.com wrote: Because of that I decided to call start_streaming first, before the __enqueue_in_driver() to ensure the drivers will get their methods called always in the same order, whatever used does. It still seems like the wrong order to me; it means that start_streaming() can't actually start streaming. But, as has been pointed out, the driver can't count on the buffers being there in any case. This ordering does, at least, expose situations where the driver author didn't think that buffers might not have been queued yet. (BTW, lest people think I'm complaining too much, let it be said that vb2 is, indeed, a big improvement over its predecessor.) I'm aware of this issue and I definitely don't threat your comments as complaining. Right now there are just a few drivers that use vb2 so it is quite easy to fix or change some design ideas. I've thought a bit more about the current design and I must confess that in fact it is suboptimal. Probably during vb2 development I've focused too much on vivi and mem2mem devices which were used for testing the framework. Usually for mem2mem case streamon() operations don't touch DMA engines, so I've missed the point that DMA engine for typical capture or output device should be activated there with some buffers already queued. Now we also know that there are drivers that may need to start dma engine in buffer_queue and stop it in the isr (before buffer_done). Capturing a single frame with camera sensor (taking a picture) is one of such examples. I have an idea to introduce a new flags to let device driver tell vb2 weather it supports 'streaming without buffers' or not. This way the order of operations in vb2_streamon() function can be switched and vb2 can also return an error if one will try to enable streaming on device that cannot do it without buffers pre-queued. This way most of typical capture and output drivers will be happy. They will just use the 'overwrite last frame' technique to guarantee that there is at least one buffer for the dma engine all the time when streaming is enable. Mem2mem (and these special 'streaming without buffers' capable) drivers will just set these flags and continue enabling/disabling dma engine per-frame basis. I will try to post the patches soon. Best regards -- Marek Szyprowski Samsung Poland RD Center -- 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] vtunerc - virtual DVB device driver
Em 21-06-2011 12:09, Andreas Oberritter escreveu: On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote: Em 21-06-2011 11:15, Andreas Oberritter escreveu: On 06/21/2011 03:44 PM, Devin Heitmueller wrote: On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter o...@linuxtv.org wrote: Mauro and Devin, I think you're missing the point. This is not about creating drivers in userspace. This is not about open or closed source. The vtuner interface, as implemented for the Dreambox, is used to access remote tuners: Put x tuners into y boxes and access them from another box as if they were local. It's used in conjunction with further software to receive the transport stream over a network connection. Honza's code does the same thing. I'm not missing the point at all. I realize exactly what Honza is trying to accomplish (and from a purely technical standpoint, it's not a bad approach) - but I'm talking about the effects of such a driver being introduced which changes the kernel/userland licensing boundary and has very real implications with how the in-kernel code is accessed. You don't need it in order to create closed source drivers. You can already create closed kernel drivers now. Also, you can create tuner drivers in userspace using the i2c-dev interface. If you like to connect a userspace driver to a DVB API device node, you can distribute a small (open or closed) wrapper with it. So what are you arguing about? Everything you're feared of can already be done since virtually forever. I disagree. There is currently no API which allows applications to issue tuning requests into the DVB core, and have those requests proxied back out to userland where an application can then use i2c-dev to tune the actual device. Meaning if somebody wants to write a closed source userland application which controls the tuner, he/she can do that (while not conforming to the DVB API). But if if he wants to reuse the GPL licensed DVB core, he has to replace the entire DVB core. The introduction of this patch makes it trivial for a third party to provide closed-source userland support for tuners while reusing all the existing GPL driver code that makes up the framework. I used to work for a vendor that makes tuners, and they do a bunch of Linux work. And that work has resulted in a bunch of open source drivers. I can tell you though that *every* conversation I've had regarding a new driver goes something like this: === Devin, we need to support tuner X under Linux. Great! I'll be happy to write a new GPL driver for the tuner/demodulator/whatever for that device But to save time/money, we just want to reuse the Windows driver code (or reference code from the vendor). Ok. Well, what is the licensing for that code? Is it GPL compatible? Not currently. So can we just make our driver closed source? Well, you can't reuse any of the existing DVB core functionality or any of the other GPL drivers (tuners, bridges, demods), so you would have rewrite all that from scratch. Oh, that would be a ton of work. Can we maybe write some userland stuff that controls the demodulator which we can keep closed source? Since it's not in the kernel, the GPL won't apply. Well, you can't really do that because there is no way for the DVB core to call back out to userland when the application makes the tuning request to the DVB core. Oh, ok then. I guess we'll have to talk to the vendor and get them to give us the reference driver code under the GPL. === I can tell you without a doubt that if this driver were present in the kernel, that going forward that vendor would have *zero* interest in doing any GPL driver work. Why would they? Why give away the code which could potentially help their competitors if they can keep it safe and protected while still being able to reuse everybody else's contributions? Companies don't contribute GPL code out of good will. They do it because they are compelled to by licenses or because there is no economically viable alternative. Mauro, ultimately it is your decision as the maintainer which drivers get accepted in to the kernel. I can tell you though that this will be a very bad thing for the driver ecosystem as a whole - it will essentially make it trivial for vendors (some of which who are doing GPL work now) to provide solutions that reuse the GPL'd DVB core without having to make any of their stuff open source. Anyway, I said in my last email that would be my last email on the topic. I guess I lied. Yes, and you did lie to your vendor, too, as you did not mention the possibilities to create 1.) closed source modules derived from existing vendor drivers while still being able to use other drivers (c.f. EXPORT_SYMBOL vs. EXPORT_SYMBOL_GPL). AFAIK, the legal issues on writing a closed source driver using EXPORT_SYMBOL are not proofed legally in any court. While EXPORT_SYMBOL_GPL explicitly adds a restriction, not
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/21 Mauro Carvalho Chehab mche...@redhat.com: Em 21-06-2011 10:44, Devin Heitmueller escreveu: Mauro, ultimately it is your decision as the maintainer which drivers get accepted in to the kernel. I can tell you though that this will be a very bad thing for the driver ecosystem as a whole - it will essentially make it trivial for vendors (some of which who are doing GPL work now) to provide solutions that reuse the GPL'd DVB core without having to make any of their stuff open source. I was a little faster to answer to my previous emails. I'm not feeling well today due to a strong pain on my backbone. So, let me explain what would be ok, from my POV: A kernelspace driver that will follow DVBv5 API and talk with wit another device via the Kernel network stack, in order to access a remote Kernel board, or a kernel board at the physical machine, for virtual machines. That means that the dvb stack won't be proxied to an userspace application. Something like: Userspace app (like kaffeine, dvr, etc) - DVB net_tunnel driver - Kernel Network stack Kernel Network stack - DVB net_tunnel driver - DVB hardware for such a design a developer should be fired ^^ Everything back to ring 0, however I guess that particular developer who designed this does not know about that security concept, otherwise he wouldn't propose to put such things into kernelspace. and from the kernel network stack you go via TCP and connect to whoever you want (particular userspace daemon with all the implementation). Aside of the security issue which it introduces you won't even protect what you try to protect because you cannot control the connection. It would be interesting if someone would implement it that way now, so Mauro disqualified himself with this proposal. Although please continue I'll keep watching, either result (supporting or not supporting it) is fine with me. Markus In other words, the DVB net_tunnel driver will take care of using the network stack, implement Kernel namespaces, etc, in order to allow virtualizing a remote hardware, without needing any userspace driver for doing that (well, except, of course, for the standard network userspace applications for DNS solving, configuring IP routes, etc). Cheers, Mauro -- 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 -- 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: vb2: holding buffers until after start_streaming()
On Tue, 21 Jun 2011 18:07:03 +0200 Marek Szyprowski m.szyprow...@samsung.com wrote: I have an idea to introduce a new flags to let device driver tell vb2 weather it supports 'streaming without buffers' or not. This way the order of operations in vb2_streamon() function can be switched and vb2 can also return an error if one will try to enable streaming on device that cannot do it without buffers pre-queued. Do you really need a flag? If a driver absolutely cannot stream without buffers queued (and can't be fixed to start streaming for real when the buffers show up) it should just return -EINVAL from start_streaming() or some such. The driver must be aware of its limitations regardless, but there's no need to push that awareness into vb2 as well. (FWIW, I wouldn't switch the order of operations in vb2_streamon(); I would just take out the if (q-streaming) test at the end of vb2_qbuf() and pass the buffers through directly. But maybe that's just me.) Thanks, jon -- 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] cx23885: Add IR Rx support for HVR-1270 boards
Em 09-06-2011 01:12, Dark Shadow escreveu: On Wed, Jun 8, 2011 at 9:27 PM, Dark Shadow shadowofdarkn...@gmail.com wrote: On Wed, Jun 8, 2011 at 9:17 PM, Dark Shadow shadowofdarkn...@gmail.com wrote: On Wed, Jun 8, 2011 at 8:31 PM, Dark Shadow shadowofdarkn...@gmail.com wrote: On Wed, Jun 8, 2011 at 7:34 PM, Andy Walls awa...@md.metrocast.net wrote: Dark Shadow shadowofdarkn...@gmail.com wrote: On Wed, Jun 8, 2011 at 6:24 PM, Andy Walls awa...@md.metrocast.net wrote: On Wed, 2011-06-08 at 13:18 -0600, Dark Shadow wrote: On Wed, Jun 8, 2011 at 4:19 AM, Andy Walls awa...@md.metrocast.net wrote: Dark Shadow shadowofdarkn...@gmail.com wrote: I have a capture card that was sold as a Hauppauge HVR-1250 (according to the box) that I am trying to use but I am having trouble getting all it's features at once. When I leave it auto detected by the module I have working TV in MythTV even though it thinks it is a 1270 but IR isn't setup. dmesg outputs #modprobe cx23885 enable_885_ir=1 [7.592714] cx23885 driver version 0.0.2 loaded [7.592748] cx23885 :07:00.0: PCI INT A - GSI 17 (level, low) - IRQ 17 [7.592926] CORE cx23885[0]: subsystem: 0070:2211, board: Hauppauge WinTV-HVR1270 [card=18,autodetected] [7.728163] IR JVC protocol handler initialized [7.738971] tveeprom 0-0050: Hauppauge model 22111, rev C2F5, serial# 6429897 [7.738974] tveeprom 0-0050: MAC address is 00:0d:fe:62:1c:c9 [7.738975] tveeprom 0-0050: tuner model is NXP 18271C2 (idx 155, type 54) [7.738977] tveeprom 0-0050: TV standards NTSC(M) ATSC/DVB Digital (eeprom 0x88) [7.738979] tveeprom 0-0050: audio processor is CX23888 (idx 40) [7.738980] tveeprom 0-0050: decoder processor is CX23888 (idx 34) [7.738982] tveeprom 0-0050: has no radio, has IR receiver, has no IR transmitter [7.738983] cx23885[0]: hauppauge eeprom: model=22111 [7.738985] cx23885_dvb_register() allocating 1 frontend(s) [7.738991] cx23885[0]: cx23885 based dvb card [7.961122] IR Sony protocol handler initialized [7.977301] tda18271 1-0060: creating new instance [7.979325] TDA18271HD/C2 detected @ 1-0060 [8.209663] DVB: registering new adapter (cx23885[0]) [8.209668] DVB: registering adapter 0 frontend 0 (LG Electronics LGDT3305 VSB/QAM Frontend)... [8.210095] cx23885_dev_checkrevision() Hardware revision = 0xd0 [8.210101] cx23885[0]/0: found at :07:00.0, rev: 4, irq: 17, latency: 0, mmio: 0xf7c0 [8.210109] cx23885 :07:00.0: setting latency timer to 64 [8.210186] cx23885 :07:00.0: irq 49 for MSI/MSI-X #ir-keytable -a /etc/rc_maps.cfg Old keytable cleared Wrote 136 keycode(s) to driver Protocols changed to RC-5 I have heard this should show up as a normal keyboard to the system but no button presses cause anything to happen to the system and trying lirc with devinput (with devinput lircd.conf) and then opening irw doesn't show any button presses either Don't force your card to a 1250, if the driver detects it is a 1270 with a CX23888 chip. No need to use the enable_885_ir parameter with a CX23888 chip, either. It only applies for two board models with actual CX23885 chips. Use of IR with the CX23888 chip should be realtively trouble free, *if* the 1270's IR has been enabled in the driver code. It likely has not been. I don't have the source code in front of me at the moment to check. It shouldn't be hard for anyone to patch a few files in the cx23885 driver to add it. Patches are welcome... Under auto detect without the enable_885_ir there is no difference so I can only hope someone will add support for it. I wasn't kidding when I said the patch is sholdn't be hard for anyone. It is really, really simple cut-and-paste job. In fact here is an *untested* patch. Regards, Andy cx23885: Add IR Rx support for HVR-1270 boards Signed-off-by: Andy Walls awa...@md.metrocast.net diff --git a/drivers/media/video/cx23885/cx23885-cards.c b/drivers/media/video/cx23885/cx23885-cards.c index ea88722..5635588 100644 --- a/drivers/media/video/cx23885/cx23885-cards.c +++ b/drivers/media/video/cx23885/cx23885-cards.c @@ -1097,12 +1097,19 @@ int cx23885_ir_init(struct cx23885_dev *dev) case CX23885_BOARD_HAUPPAUGE_HVR1800: case CX23885_BOARD_HAUPPAUGE_HVR1200: case CX23885_BOARD_HAUPPAUGE_HVR1400: - case CX23885_BOARD_HAUPPAUGE_HVR1270: case CX23885_BOARD_HAUPPAUGE_HVR1275: case CX23885_BOARD_HAUPPAUGE_HVR1255: case CX23885_BOARD_HAUPPAUGE_HVR1210: /* FIXME: Implement me */ break; + case CX23885_BOARD_HAUPPAUGE_HVR1270: + ret = cx23888_ir_probe(dev); + if (ret) + break; + dev-sd_ir = cx23885_find_hw(dev, CX23885_HW_888_IR); + v4l2_subdev_call(dev-sd_cx25840, core, s_io_pin_config, +
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/21 Mauro Carvalho Chehab mche...@redhat.com: Em 21-06-2011 12:09, Andreas Oberritter escreveu: On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote: Em 21-06-2011 11:15, Andreas Oberritter escreveu: On 06/21/2011 03:44 PM, Devin Heitmueller wrote: On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter o...@linuxtv.org wrote: Mauro and Devin, I think you're missing the point. This is not about creating drivers in userspace. This is not about open or closed source. The vtuner interface, as implemented for the Dreambox, is used to access remote tuners: Put x tuners into y boxes and access them from another box as if they were local. It's used in conjunction with further software to receive the transport stream over a network connection. Honza's code does the same thing. I'm not missing the point at all. I realize exactly what Honza is trying to accomplish (and from a purely technical standpoint, it's not a bad approach) - but I'm talking about the effects of such a driver being introduced which changes the kernel/userland licensing boundary and has very real implications with how the in-kernel code is accessed. You don't need it in order to create closed source drivers. You can already create closed kernel drivers now. Also, you can create tuner drivers in userspace using the i2c-dev interface. If you like to connect a userspace driver to a DVB API device node, you can distribute a small (open or closed) wrapper with it. So what are you arguing about? Everything you're feared of can already be done since virtually forever. I disagree. There is currently no API which allows applications to issue tuning requests into the DVB core, and have those requests proxied back out to userland where an application can then use i2c-dev to tune the actual device. Meaning if somebody wants to write a closed source userland application which controls the tuner, he/she can do that (while not conforming to the DVB API). But if if he wants to reuse the GPL licensed DVB core, he has to replace the entire DVB core. The introduction of this patch makes it trivial for a third party to provide closed-source userland support for tuners while reusing all the existing GPL driver code that makes up the framework. I used to work for a vendor that makes tuners, and they do a bunch of Linux work. And that work has resulted in a bunch of open source drivers. I can tell you though that *every* conversation I've had regarding a new driver goes something like this: === Devin, we need to support tuner X under Linux. Great! I'll be happy to write a new GPL driver for the tuner/demodulator/whatever for that device But to save time/money, we just want to reuse the Windows driver code (or reference code from the vendor). Ok. Well, what is the licensing for that code? Is it GPL compatible? Not currently. So can we just make our driver closed source? Well, you can't reuse any of the existing DVB core functionality or any of the other GPL drivers (tuners, bridges, demods), so you would have rewrite all that from scratch. Oh, that would be a ton of work. Can we maybe write some userland stuff that controls the demodulator which we can keep closed source? Since it's not in the kernel, the GPL won't apply. Well, you can't really do that because there is no way for the DVB core to call back out to userland when the application makes the tuning request to the DVB core. Oh, ok then. I guess we'll have to talk to the vendor and get them to give us the reference driver code under the GPL. === I can tell you without a doubt that if this driver were present in the kernel, that going forward that vendor would have *zero* interest in doing any GPL driver work. Why would they? Why give away the code which could potentially help their competitors if they can keep it safe and protected while still being able to reuse everybody else's contributions? Companies don't contribute GPL code out of good will. They do it because they are compelled to by licenses or because there is no economically viable alternative. Mauro, ultimately it is your decision as the maintainer which drivers get accepted in to the kernel. I can tell you though that this will be a very bad thing for the driver ecosystem as a whole - it will essentially make it trivial for vendors (some of which who are doing GPL work now) to provide solutions that reuse the GPL'd DVB core without having to make any of their stuff open source. Anyway, I said in my last email that would be my last email on the topic. I guess I lied. Yes, and you did lie to your vendor, too, as you did not mention the possibilities to create 1.) closed source modules derived from existing vendor drivers while still being able to use other drivers (c.f. EXPORT_SYMBOL vs. EXPORT_SYMBOL_GPL). AFAIK, the legal issues on writing a closed source driver using EXPORT_SYMBOL are not proofed legally in any court. While
Re: [PATCH 2/2] radio-timb: Add open function which finds tuner and DSP via I2C
Em 10-06-2011 11:48, Richard Röjfors escreveu:
This patch uses the platform data and finds a tuner and DSP. This is
done when the user calls open. Not during probe, to allow shorter bootup
time of the system.
This piece of code was actually missing earlier, many of the functions
were not useful without DSP and tuner.
Signed-off-by: Richard Röjfors richard.rojf...@pelagicore.com
---
diff --git a/drivers/media/radio/radio-timb.c
b/drivers/media/radio/radio-timb.c
index a185610..64a5e19 100644
--- a/drivers/media/radio/radio-timb.c
+++ b/drivers/media/radio/radio-timb.c
@@ -141,9 +141,42 @@ static const struct v4l2_ioctl_ops timbradio_ioctl_ops =
{
.vidioc_s_ctrl = timbradio_vidioc_s_ctrl
};
+static int timbradio_fops_open(struct file *file)
+{
+ struct timbradio *tr = video_drvdata(file);
+ struct i2c_adapter *adapt;
+
+ /* find the I2C bus */
+ adapt = i2c_get_adapter(tr-pdata.i2c_adapter);
+ if (!adapt) {
+ printk(KERN_ERR DRIVER_NAME: No I2C bus\n);
+ return -ENODEV;
+ }
+
+ /* now find the tuner and dsp */
+ if (!tr-sd_dsp)
+ tr-sd_dsp = v4l2_i2c_new_subdev_board(tr-v4l2_dev, adapt,
+ tr-pdata.dsp, NULL);
+
+ if (!tr-sd_tuner)
+ tr-sd_tuner = v4l2_i2c_new_subdev_board(tr-v4l2_dev, adapt,
+ tr-pdata.tuner, NULL);
+
+ i2c_put_adapter(adapt);
Hmm... it doesn't look right to me to do that for every device
open. You should probably do it at device probe, and move i2c_put_adapter
to device removal.
+
+ if (!tr-sd_tuner || !tr-sd_dsp) {
+ printk(KERN_ERR DRIVER_NAME
+ : Failed to get tuner or DSP\n);
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
static const struct v4l2_file_operations timbradio_fops = {
.owner = THIS_MODULE,
.unlocked_ioctl = video_ioctl2,
+ .open = timbradio_fops_open,
};
static int __devinit timbradio_probe(struct platform_device *pdev)
--
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
--
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] cx23885: Add IR Rx support for HVR-1270 boards
Mauro Carvalho Chehab mche...@redhat.com wrote: Em 09-06-2011 01:12, Dark Shadow escreveu: On Wed, Jun 8, 2011 at 9:27 PM, Dark Shadow shadowofdarkn...@gmail.com wrote: On Wed, Jun 8, 2011 at 9:17 PM, Dark Shadow shadowofdarkn...@gmail.com wrote: On Wed, Jun 8, 2011 at 8:31 PM, Dark Shadow shadowofdarkn...@gmail.com wrote: On Wed, Jun 8, 2011 at 7:34 PM, Andy Walls awa...@md.metrocast.net wrote: Dark Shadow shadowofdarkn...@gmail.com wrote: On Wed, Jun 8, 2011 at 6:24 PM, Andy Walls awa...@md.metrocast.net wrote: On Wed, 2011-06-08 at 13:18 -0600, Dark Shadow wrote: On Wed, Jun 8, 2011 at 4:19 AM, Andy Walls awa...@md.metrocast.net wrote: Dark Shadow shadowofdarkn...@gmail.com wrote: I have a capture card that was sold as a Hauppauge HVR-1250 (according to the box) that I am trying to use but I am having trouble getting all it's features at once. When I leave it auto detected by the module I have working TV in MythTV even though it thinks it is a 1270 but IR isn't setup. dmesg outputs #modprobe cx23885 enable_885_ir=1 [7.592714] cx23885 driver version 0.0.2 loaded [7.592748] cx23885 :07:00.0: PCI INT A - GSI 17 (level, low) - IRQ 17 [7.592926] CORE cx23885[0]: subsystem: 0070:2211, board: Hauppauge WinTV-HVR1270 [card=18,autodetected] [7.728163] IR JVC protocol handler initialized [7.738971] tveeprom 0-0050: Hauppauge model 22111, rev C2F5, serial# 6429897 [7.738974] tveeprom 0-0050: MAC address is 00:0d:fe:62:1c:c9 [7.738975] tveeprom 0-0050: tuner model is NXP 18271C2 (idx 155, type 54) [7.738977] tveeprom 0-0050: TV standards NTSC(M) ATSC/DVB Digital (eeprom 0x88) [7.738979] tveeprom 0-0050: audio processor is CX23888 (idx 40) [7.738980] tveeprom 0-0050: decoder processor is CX23888 (idx 34) [7.738982] tveeprom 0-0050: has no radio, has IR receiver, has no IR transmitter [7.738983] cx23885[0]: hauppauge eeprom: model=22111 [7.738985] cx23885_dvb_register() allocating 1 frontend(s) [7.738991] cx23885[0]: cx23885 based dvb card [7.961122] IR Sony protocol handler initialized [7.977301] tda18271 1-0060: creating new instance [7.979325] TDA18271HD/C2 detected @ 1-0060 [8.209663] DVB: registering new adapter (cx23885[0]) [8.209668] DVB: registering adapter 0 frontend 0 (LG Electronics LGDT3305 VSB/QAM Frontend)... [8.210095] cx23885_dev_checkrevision() Hardware revision = 0xd0 [8.210101] cx23885[0]/0: found at :07:00.0, rev: 4, irq: 17, latency: 0, mmio: 0xf7c0 [8.210109] cx23885 :07:00.0: setting latency timer to 64 [8.210186] cx23885 :07:00.0: irq 49 for MSI/MSI-X #ir-keytable -a /etc/rc_maps.cfg Old keytable cleared Wrote 136 keycode(s) to driver Protocols changed to RC-5 I have heard this should show up as a normal keyboard to the system but no button presses cause anything to happen to the system and trying lirc with devinput (with devinput lircd.conf) and then opening irw doesn't show any button presses either Don't force your card to a 1250, if the driver detects it is a 1270 with a CX23888 chip. No need to use the enable_885_ir parameter with a CX23888 chip, either. It only applies for two board models with actual CX23885 chips. Use of IR with the CX23888 chip should be realtively trouble free, *if* the 1270's IR has been enabled in the driver code. It likely has not been. I don't have the source code in front of me at the moment to check. It shouldn't be hard for anyone to patch a few files in the cx23885 driver to add it. Patches are welcome... Under auto detect without the enable_885_ir there is no difference so I can only hope someone will add support for it. I wasn't kidding when I said the patch is sholdn't be hard for anyone. It is really, really simple cut-and-paste job. In fact here is an *untested* patch. Regards, Andy cx23885: Add IR Rx support for HVR-1270 boards Signed-off-by: Andy Walls awa...@md.metrocast.net diff --git a/drivers/media/video/cx23885/cx23885-cards.c b/drivers/media/video/cx23885/cx23885-cards.c index ea88722..5635588 100644 --- a/drivers/media/video/cx23885/cx23885-cards.c +++ b/drivers/media/video/cx23885/cx23885-cards.c @@ -1097,12 +1097,19 @@ int cx23885_ir_init(struct cx23885_dev *dev) case CX23885_BOARD_HAUPPAUGE_HVR1800: case CX23885_BOARD_HAUPPAUGE_HVR1200: case CX23885_BOARD_HAUPPAUGE_HVR1400: - case CX23885_BOARD_HAUPPAUGE_HVR1270: case CX23885_BOARD_HAUPPAUGE_HVR1275: case CX23885_BOARD_HAUPPAUGE_HVR1255: case CX23885_BOARD_HAUPPAUGE_HVR1210: /* FIXME: Implement me */ break; + case CX23885_BOARD_HAUPPAUGE_HVR1270: + ret = cx23888_ir_probe(dev); + if (ret) + break; + dev-sd_ir = cx23885_find_hw(dev, CX23885_HW_888_IR); +
[PATCH] uvcvideo: Add FIX_BANDWIDTH quirk to HP Webcam found on HP Mini 5103 netbook
The camera there identifeis itself as being manufactured by Cheng Uei
Precision Industry Co., Ltd (Foxlink), and product is titled as HP
Webcam [2 MP Fixed].
I was trying to get 2 USB video capture devices to work simultaneously,
and noticed that the above mentioned webcam always requires packet size
= 3072 bytes per micro frame (~= 23.4 MB/s isoc bandwidth), which is far
more than enough to get standard NTSC 640x480x2x30 = ~17.6 MB/s isoc
bandwidth.
As there are alt interfaces with smaller MxPS
T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 2 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=05c8 ProdID=0403 Rev= 1.06
S: Manufacturer=Foxlink
S: Product=HP Webcam [2 MP Fixed]
S: SerialNumber=200909240102
C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA
A: FirstIf#= 0 IfCount= 2 Cls=0e(video) Sub=03 Prot=00
I:* If#= 0 Alt= 0 #EPs= 1 Cls=0e(video) Sub=01 Prot=00 Driver=uvcvideo
E: Ad=83(I) Atr=03(Int.) MxPS= 16 Ivl=4ms
I:* If#= 1 Alt= 0 #EPs= 0 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
I: If#= 1 Alt= 1 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
E: Ad=81(I) Atr=05(Isoc) MxPS= 128 Ivl=125us
I: If#= 1 Alt= 2 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
E: Ad=81(I) Atr=05(Isoc) MxPS= 512 Ivl=125us
I: If#= 1 Alt= 3 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
E: Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us
I: If#= 1 Alt= 4 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
E: Ad=81(I) Atr=05(Isoc) MxPS=1536 Ivl=125us
I: If#= 1 Alt= 5 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
E: Ad=81(I) Atr=05(Isoc) MxPS=2048 Ivl=125us
I: If#= 1 Alt= 6 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
E: Ad=81(I) Atr=05(Isoc) MxPS=2688 Ivl=125us
I: If#= 1 Alt= 7 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
E: Ad=81(I) Atr=05(Isoc) MxPS=3072 Ivl=125us
UVC_QUIRK_FIX_BANDWIDTH helps here and NTSC video can be served with
MxPS=2688 i.e. 20.5 MB/s isoc bandwidth.
In terms of microframe time allocation, before the quirk NTSC video
required 60 usecs / microframe and 53 usecs / microframe after.
P.S. Now with tweaked ehci-hcd to allow up to 90% isoc bandwith (instead of
allowed for high speed 80%) I can capture two video sources -- PAL 720x576
YUV422 @25fps + NTSC 640x480 YUV422 @30fps simultaneously. Hooray!
Signed-off-by: Kirill Smelkov k...@mns.spb.ru
---
drivers/media/video/uvc/uvc_driver.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_driver.c
b/drivers/media/video/uvc/uvc_driver.c
index b6eae48..f633700 100644
--- a/drivers/media/video/uvc/uvc_driver.c
+++ b/drivers/media/video/uvc/uvc_driver.c
@@ -2130,6 +2130,15 @@ static struct usb_device_id uvc_ids[] = {
.bInterfaceProtocol = 0,
.driver_info = UVC_QUIRK_PROBE_MINMAX
| UVC_QUIRK_BUILTIN_ISIGHT },
+ /* Foxlink (HP Webcam on HP Mini 5103) */
+ { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
+ | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x05c8,
+ .idProduct= 0x0403,
+ .bInterfaceClass = USB_CLASS_VIDEO,
+ .bInterfaceSubClass = 1,
+ .bInterfaceProtocol = 0,
+ .driver_info = UVC_QUIRK_FIX_BANDWIDTH },
/* Genesys Logic USB 2.0 PC Camera */
{ .match_flags = USB_DEVICE_ID_MATCH_DEVICE
| USB_DEVICE_ID_MATCH_INT_INFO,
--
1.7.6.rc1
--
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
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Tue Jun 21 19:00:13 CEST 2011 git hash:b484e482fc789beb4df0b6770884df6b1e4c1cf4 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS spec-git: ERRORS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- 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: [RESEND PATCH v19 0/6] davinci vpbe: dm6446 v4l2 driver
Em 17-06-2011 04:03, Hadli, Manjunath escreveu: Mauro, Can you consider this patch series for a pull? Next time, could you please add on your tree and send me a git pull request? Patchwork is currently not reliable. I have a backup process, but a git pull request works better and I won't have the risk of applying the wrong patches or at a wrong order. In this specific case, as all patches were caught by patchwork, I'll apply from your emails after reviewing them. Thanks, Mauro -Manju On Fri, Jun 17, 2011 at 12:31:30, Hadli, Manjunath wrote: fixed a wrong file inclusion in one of the patches Manjunath Hadli (6): davinci vpbe: V4L2 display driver for DM644X SoC davinci vpbe: VPBE display driver davinci vpbe: OSD(On Screen Display) block davinci vpbe: VENC( Video Encoder) implementation davinci vpbe: Build infrastructure for VPBE driver davinci vpbe: Readme text for Dm6446 vpbe Documentation/video4linux/README.davinci-vpbe | 93 ++ drivers/media/video/davinci/Kconfig | 23 + drivers/media/video/davinci/Makefile |2 + drivers/media/video/davinci/vpbe.c| 864 drivers/media/video/davinci/vpbe_display.c| 1860 + drivers/media/video/davinci/vpbe_osd.c| 1231 drivers/media/video/davinci/vpbe_osd_regs.h | 364 + drivers/media/video/davinci/vpbe_venc.c | 566 drivers/media/video/davinci/vpbe_venc_regs.h | 177 +++ include/media/davinci/vpbe.h | 184 +++ include/media/davinci/vpbe_display.h | 147 ++ include/media/davinci/vpbe_osd.h | 394 ++ include/media/davinci/vpbe_types.h| 91 ++ include/media/davinci/vpbe_venc.h | 45 + 14 files changed, 6041 insertions(+), 0 deletions(-) create mode 100644 Documentation/video4linux/README.davinci-vpbe create mode 100644 drivers/media/video/davinci/vpbe.c create mode 100644 drivers/media/video/davinci/vpbe_display.c create mode 100644 drivers/media/video/davinci/vpbe_osd.c create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h create mode 100644 drivers/media/video/davinci/vpbe_venc.c create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h create mode 100644 include/media/davinci/vpbe.h create mode 100644 include/media/davinci/vpbe_display.h create mode 100644 include/media/davinci/vpbe_osd.h create mode 100644 include/media/davinci/vpbe_types.h create mode 100644 include/media/davinci/vpbe_venc.h -- 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 -- 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 5/5] marvell-cam: implement contiguous DMA operation
Em 20-06-2011 16:14, Jonathan Corbet escreveu:
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.
Patch looks correct.
A side note for vb2 maintainers:
IMO, vb2 core should take the responsibility to allow to switch between DMA
scatter/gather and continuous (and, eventually, vmalloc), where the bridge
driver
support more than one option.
Otherwise, we'll end by having codes similar to that on all drivers that can be
used
on different architectures.
Signed-off-by: Jonathan Corbet cor...@lwn.net
---
drivers/media/video/marvell-ccic/Kconfig |1 +
drivers/media/video/marvell-ccic/cafe-driver.c |6 +
drivers/media/video/marvell-ccic/mcam-core.c | 230
++--
drivers/media/video/marvell-ccic/mcam-core.h | 21 ++-
drivers/media/video/marvell-ccic/mmp-driver.c |1 +
5 files changed, 205 insertions(+), 54 deletions(-)
diff --git a/drivers/media/video/marvell-ccic/Kconfig
b/drivers/media/video/marvell-ccic/Kconfig
index eb535b1..22314a0 100644
--- a/drivers/media/video/marvell-ccic/Kconfig
+++ b/drivers/media/video/marvell-ccic/Kconfig
@@ -14,6 +14,7 @@ config VIDEO_MMP_CAMERA
select VIDEO_OV7670
select I2C_GPIO
select VIDEOBUF2_VMALLOC
+ select VIDEOBUF2_DMA_CONTIG
---help---
This is a Video4Linux2 driver for the integrated camera
controller found on Marvell Armada 610 application
diff --git a/drivers/media/video/marvell-ccic/cafe-driver.c
b/drivers/media/video/marvell-ccic/cafe-driver.c
index 6a29cc1..d030f9b 100644
--- a/drivers/media/video/marvell-ccic/cafe-driver.c
+++ b/drivers/media/video/marvell-ccic/cafe-driver.c
@@ -482,6 +482,12 @@ static int cafe_pci_probe(struct pci_dev *pdev,
mcam-clock_speed = 45;
mcam-use_smbus = 1;
/*
+ * Vmalloc mode for buffers is traditional with this driver.
+ * We *might* be able to run DMA_contig, especially on a system
+ * with CMA in it.
+ */
+ mcam-buffer_mode = B_vmalloc;
+ /*
* Get set up on the PCI bus.
*/
ret = pci_enable_device(pdev);
diff --git a/drivers/media/video/marvell-ccic/mcam-core.c
b/drivers/media/video/marvell-ccic/mcam-core.c
index ca3c56f..419b4e5 100644
--- a/drivers/media/video/marvell-ccic/mcam-core.c
+++ b/drivers/media/video/marvell-ccic/mcam-core.c
@@ -25,9 +25,16 @@
#include media/v4l2-chip-ident.h
#include media/ov7670.h
#include media/videobuf2-vmalloc.h
+#include media/videobuf2-dma-contig.h
#include mcam-core.h
+/*
+ * Basic frame stats - to be deleted shortly
+ */
+static int frames;
+static int singles;
+static int delivered;
/*
* Internal DMA buffer management. Since the controller cannot do S/G I/O,
@@ -48,7 +55,8 @@ MODULE_PARM_DESC(alloc_bufs_at_read,
Non-zero value causes DMA buffers to be allocated when the
video capture device is read, rather than at module load
time. This saves memory, but decreases the chances of
- successfully getting those buffers.);
+ successfully getting those buffers. This parameter is
+ only used in the vmalloc buffer mode);
static int n_dma_bufs = 3;
module_param(n_dma_bufs, uint, 0644);
@@ -82,6 +90,13 @@ MODULE_PARM_DESC(flip,
If set, the sensor will be instructed to flip the image
vertically.);
+static int buffer_mode = -1;
+module_param(buffer_mode, int, 0444);
+MODULE_PARM_DESC(buffer_mode,
+ Set the buffer mode to be used; default is to go with what
+ the platform driver asks for. Set to 0 for vmalloc, 1 for
+ DMA contiguous.);
+
/*
* Status flags. Always manipulated with bit operations.
*/
@@ -90,6 +105,7 @@ MODULE_PARM_DESC(flip,
#define CF_BUF2_VALID 2
#define CF_DMA_ACTIVE 3 /* A frame is incoming */
#define CF_CONFIG_NEEDED 4 /* Must configure hardware */
+#define CF_SINGLE_BUFFER 5 /* Running with a single buffer */
#define sensor_call(cam, o, f, args...) \
v4l2_subdev_call(cam-sensor, o, f, ##args)
@@ -197,10 +213,9 @@ static inline struct mcam_vb_buffer *vb_to_mvb(struct
vb2_buffer *vb)
*/
/*
- * Do everything we think we need to have the interface operating
- * according to the desired format.
+ * Set up DMA buffers when operating in vmalloc mode
*/
-static void mcam_ctlr_dma(struct mcam_camera *cam)
+static void mcam_ctlr_dma_vmalloc(struct mcam_camera *cam)
{
/*
* Store the first two Y buffers (we aren't supporting
@@ -219,6 +234,57 @@ static void mcam_ctlr_dma(struct mcam_camera *cam)
mcam_reg_write(cam, REG_UBAR, 0); /* 32 bits only */
}
+/*
+ * Set up a contiguous buffer for the
Re: [PATCH/RFC] fbdev: Add FOURCC-based format configuration API
Hi Laurent,
On Tue, Jun 21, 2011 at 17:36, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
+The following types and visuals are supported.
+
+- FB_TYPE_PACKED_PIXELS
+
+- FB_TYPE_PLANES
You forgot FB_TYPE_INTERLEAVED_PLANES, FB_TYPE_TEXT, and
FB_TYPE_VGA_PLANES. Ah, that's the feel free to extend the API doc :-)
+The FOURCC-based API replaces format descriptions by four character codes
+(FOURCC). FOURCCs are abstract identifiers that uniquely define a format
+without explicitly describing it. This is the only API that supports YUV
+formats. Drivers are also encouraged to implement the FOURCC-based API for
RGB
+and grayscale formats.
+
+Drivers that support the FOURCC-based API report this capability by setting
+the FB_CAP_FOURCC bit in the fb_fix_screeninfo capabilities field.
+
+FOURCC definitions are located in the linux/videodev2.h header. However, and
+despite starting with the V4L2_PIX_FMT_prefix, they are not restricted to
V4L2
+and don't require usage of the V4L2 subsystem. FOURCC documentation is
+available in Documentation/DocBook/v4l/pixfmt.xml.
+
+To select a format, applications set the FB_VMODE_FOURCC bit in the
+fb_var_screeninfo vmode field, and set the fourcc field to the desired
FOURCC.
+The bits_per_pixel, red, green, blue, transp and nonstd fields must be set to
+0 by applications and ignored by drivers. Note that the grayscale and fourcc
+fields share the same memory location. Application must thus not set the
+grayscale field to 0.
These are the only parts I don't like: (ab)using the vmode field (this
isn't really a
vmode flag), and the union of grayscale and fourcc (avoid unions where
possible).
What about storing the FOURCC value in nonstd instead?
As FOURCC values are always 4 ASCII characters (hence all 4 bytes must
be non-zero),
I don't think there are any conflicts with existing values of nonstd.
To make it even safer and easier to parse, you could set bit 31 of
nonstd as a FOURCC
indicator.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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: Fwd: [PATCH] ngene: blocking and nonblocking io for sec0
Haven't fully understood the usage of wake_event_interruptible, now I have read
its description. Sorry for the lame patch.
Please find a fixed version below.
Patch allows for blocking or nonblocking io on the ngene sec0 device.
It also enforces one reader and one writer at a time.
Signed-off-by: Issa Gorissen flo...@usa.net
--
--- a/linux/drivers/media/dvb/ngene/ngene-dvb.c 2011-05-10 19:11:21.0
+0200
+++ b/linux/drivers/media/dvb/ngene/ngene-dvb.c 2011-06-21 23:46:09.0
+0200
@@ -53,15 +53,30 @@ static ssize_t ts_write(struct file *fil
struct dvb_device *dvbdev = file-private_data;
struct ngene_channel *chan = dvbdev-priv;
struct ngene *dev = chan-dev;
+ int avail = 0;
+ char nonblock = file-f_flags O_NONBLOCK;
- if (wait_event_interruptible(dev-tsout_rbuf.queue,
-dvb_ringbuffer_free
-(dev-tsout_rbuf) = count) 0)
+ if (!count)
return 0;
- dvb_ringbuffer_write(dev-tsout_rbuf, buf, count);
+ if (nonblock) {
+ avail = dvb_ringbuffer_free(dev-tsout_rbuf);
+ if (!avail)
+ return -EAGAIN;
+ if (count avail)
+ avail = count;
+ } else {
+ if (wait_event_interruptible(dev-tsout_rbuf.queue,
+dvb_ringbuffer_free
+(dev-tsout_rbuf) = count) 0)
+ return -EINTR;
+
+ avail = count;
+ }
+
+ dvb_ringbuffer_write(dev-tsout_rbuf, buf, avail);
+ return avail;
- return count;
}
static ssize_t ts_read(struct file *file, char *buf,
@@ -70,22 +85,29 @@ static ssize_t ts_read(struct file *file
struct dvb_device *dvbdev = file-private_data;
struct ngene_channel *chan = dvbdev-priv;
struct ngene *dev = chan-dev;
- int left, avail;
+ int avail = 0;
+ char nonblock = file-f_flags O_NONBLOCK;
- left = count;
- while (left) {
- if (wait_event_interruptible(
- dev-tsin_rbuf.queue,
- dvb_ringbuffer_avail(dev-tsin_rbuf) 0) 0)
- return -EAGAIN;
+ if (!count)
+ return 0;
+
+ if (nonblock) {
avail = dvb_ringbuffer_avail(dev-tsin_rbuf);
- if (avail left)
- avail = left;
- dvb_ringbuffer_read_user(dev-tsin_rbuf, buf, avail);
- left -= avail;
- buf += avail;
+ if (!avail)
+ return -EAGAIN;
+ if (avail count)
+ avail = count;
+ } else {
+ if (wait_event_interruptible(dev-tsin_rbuf.queue,
+dvb_ringbuffer_avail
+(dev-tsin_rbuf) = count) 0)
+ return -EINTR;
+
+ avail = count;
}
- return count;
+
+ dvb_ringbuffer_read_user(dev-tsin_rbuf, buf, avail);
+ return avail;
}
static const struct file_operations ci_fops = {
@@ -98,9 +120,9 @@ static const struct file_operations ci_f
struct dvb_device ngene_dvbdev_ci = {
.priv= 0,
- .readers = -1,
- .writers = -1,
- .users = -1,
+ .readers = 1,
+ .writers = 1,
+ .users = 2,
.fops= ci_fops,
};
--
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/RFC] fbdev: Add FOURCC-based format configuration API
Hi Geert, On Tuesday 21 June 2011 22:49:14 Geert Uytterhoeven wrote: On Tue, Jun 21, 2011 at 17:36, Laurent Pinchart wrote: +The following types and visuals are supported. + +- FB_TYPE_PACKED_PIXELS + +- FB_TYPE_PLANES You forgot FB_TYPE_INTERLEAVED_PLANES, FB_TYPE_TEXT, and FB_TYPE_VGA_PLANES. Ah, that's the feel free to extend the API doc :-) To be honest, I don't know how they work. That's why I haven't documented them. +The FOURCC-based API replaces format descriptions by four character codes +(FOURCC). FOURCCs are abstract identifiers that uniquely define a format +without explicitly describing it. This is the only API that supports YUV +formats. Drivers are also encouraged to implement the FOURCC-based API for RGB +and grayscale formats. + +Drivers that support the FOURCC-based API report this capability by setting +the FB_CAP_FOURCC bit in the fb_fix_screeninfo capabilities field. + +FOURCC definitions are located in the linux/videodev2.h header. However, and +despite starting with the V4L2_PIX_FMT_prefix, they are not restricted to V4L2 +and don't require usage of the V4L2 subsystem. FOURCC documentation is +available in Documentation/DocBook/v4l/pixfmt.xml. + +To select a format, applications set the FB_VMODE_FOURCC bit in the +fb_var_screeninfo vmode field, and set the fourcc field to the desired FOURCC. +The bits_per_pixel, red, green, blue, transp and nonstd fields must be set to +0 by applications and ignored by drivers. Note that the grayscale and fourcc +fields share the same memory location. Application must thus not set the +grayscale field to 0. These are the only parts I don't like: (ab)using the vmode field (this isn't really a vmode flag), and the union of grayscale and fourcc (avoid unions where possible). I've proposed adding a FB_NONSTD_FORMAT bit to the nonstd field as a FOURCC mode indicator in my initial RFC. Florian Tobias Schandinat wasn't very happy with that, and proposed using the vmode field instead. Given that there's virtually no fbdev documentation, whether the vmode field and/or nonstd field are good fit for a FOURCC mode indicator is subject to interpretation. What about storing the FOURCC value in nonstd instead? Wouldn't that be a union of nonstd and fourcc ? :-) FOURCC-based format setting will be a standard fbdev API, I'm not very keen on storing it in the nonstd field without a union. As FOURCC values are always 4 ASCII characters (hence all 4 bytes must be non-zero), I don't think there are any conflicts with existing values of nonstd. To make it even safer and easier to parse, you could set bit 31 of nonstd as a FOURCC indicator. I would then create a union between nonstd and fourcc, and document nonstd as being used for the legacy API only. Most existing drivers use a couple of nonstd bits only. The driver that (ab)uses nonstd the most is pxafb and uses bits 22:0. Bits 31:24 are never used as far as I can tell, so nonstd 0xff00 != 0 could be used as a FOURCC mode test. This assumes that FOURCCs will never have their last character set to '\0'. Is that a safe assumption for the future ? -- Regards, Laurent Pinchart -- 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
[GIT PULL FOR v3.0] uvcvideo fixes
Hi Mauro, The following changes since commit 56299378726d5f2ba8d3c8cbbd13cb280ba45e4f: Linux 3.0-rc4 (2011-06-20 20:25:46 -0700) are available in the git repository at: git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-stable Sjoerd Simons (2): uvcvideo: Remove buffers from the queues when freeing uvcvideo: Disable the queue when failing to start drivers/media/video/uvc/uvc_queue.c |2 ++ drivers/media/video/uvc/uvc_video.c |4 +++- 2 files changed, 5 insertions(+), 1 deletions(-) Those patches fix bugs (including a user-triggerable oops), but they're not regression fixes. -- Regards, Laurent Pinchart -- 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] [media] uvcvideo: Fix control mapping for devices with multiple chains
Hi Stephan,
On Wednesday 01 June 2011 00:24:21 Stephan Lachowsky wrote:
The search for matching extension units fails to take account of the
current chain. In the case where you have two distinct video chains,
both containing an XU with the same GUID but different unit ids, you
will be unable to perform a mapping on the second chain because entity
on the first chain will always be found first
Fix this by only searching the current chain when performing a control
mapping. This is analogous to the search used by uvc_find_control(),
and is the correct behaviour.
Thanks for the patch. I agree with your analysis, but I'm concerned about
devices that might have extension units not connected to any chain. They would
become unaccessible.
Devices for which extension unit control mappings have been published have all
their XUs connected to a chain, so I'm OK with the patch. I will add a TODO
comment to remind me of the issue, and I'll solve the problem later if it ever
occurs.
Signed-off-by: Stephan Lachowsky stephan.lachow...@maxim-ic.com
---
drivers/media/video/uvc/uvc_ctrl.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_ctrl.c
b/drivers/media/video/uvc/uvc_ctrl.c index 59f8a9a..a77648f 100644
--- a/drivers/media/video/uvc/uvc_ctrl.c
+++ b/drivers/media/video/uvc/uvc_ctrl.c
@@ -1565,8 +1565,8 @@ int uvc_ctrl_add_mapping(struct uvc_video_chain
*chain, return -EINVAL;
}
- /* Search for the matching (GUID/CS) control in the given device */
- list_for_each_entry(entity, dev-entities, list) {
+ /* Search for the matching (GUID/CS) control on the current chain */
+ list_for_each_entry(entity, chain-entities, chain) {
unsigned int i;
if (UVC_ENTITY_TYPE(entity) != UVC_VC_EXTENSION_UNIT ||
--
Regards,
Laurent Pinchart
--
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: [Linux-uvc-devel] [PATCH] [media] uvcvideo: Fix control mapping for devices with multiple chains
Hi Stephan,
On Wednesday 22 June 2011 00:55:36 Laurent Pinchart wrote:
On Wednesday 01 June 2011 00:24:21 Stephan Lachowsky wrote:
The search for matching extension units fails to take account of the
current chain. In the case where you have two distinct video chains,
both containing an XU with the same GUID but different unit ids, you
will be unable to perform a mapping on the second chain because entity
on the first chain will always be found first
Fix this by only searching the current chain when performing a control
mapping. This is analogous to the search used by uvc_find_control(),
and is the correct behaviour.
Thanks for the patch. I agree with your analysis, but I'm concerned about
devices that might have extension units not connected to any chain. They
would become unaccessible.
Devices for which extension unit control mappings have been published have
all their XUs connected to a chain, so I'm OK with the patch. I will add a
TODO comment to remind me of the issue, and I'll solve the problem later
if it ever occurs.
Sorry, I spoke too fast. uvc_find_control() has the same issue, so there's no
need to add a comment specific to uvc_ctrl_add_mapping(). I'll apply your
patch as-is.
Signed-off-by: Stephan Lachowsky stephan.lachow...@maxim-ic.com
---
drivers/media/video/uvc/uvc_ctrl.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_ctrl.c
b/drivers/media/video/uvc/uvc_ctrl.c index 59f8a9a..a77648f 100644
--- a/drivers/media/video/uvc/uvc_ctrl.c
+++ b/drivers/media/video/uvc/uvc_ctrl.c
@@ -1565,8 +1565,8 @@ int uvc_ctrl_add_mapping(struct uvc_video_chain
*chain, return -EINVAL;
}
- /* Search for the matching (GUID/CS) control in the given device */
- list_for_each_entry(entity, dev-entities, list) {
+ /* Search for the matching (GUID/CS) control on the current chain */
+ list_for_each_entry(entity, chain-entities, chain) {
unsigned int i;
if (UVC_ENTITY_TYPE(entity) != UVC_VC_EXTENSION_UNIT ||
--
Regards,
Laurent Pinchart
--
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] vtunerc - virtual DVB device driver
My very little opinion is that waving GPL is way to the hell. Nobody told me why similar technologies, in different kernel parts are acceptable, but not here. since a customer was trying to use this module the only feedback I can give right now is that there are still some fundamental bugs in that work. Just running it with some intuitive parameters (without having a dvb device connected) caused it to hang. ./vtunerc.i686 -c 1 vtunerc: [5210 ../../vtunerc.c:349] debug: added frontend mode DVB-C as mode 0, searching for tuner types 2 vtunerc: [5210 ../../vtunerc.c:346] error: unknown tuner mode specified: 1 allow values are: -s -S -s2 -S2 -c -t it just never returned. DMESG: vtunerc: [5207 ../../vtunerc.c:593] info: fake server answer vtunerc: [5207 ../../vtunerc.c:606] info: msg: 4096 completed vtunerc: [5207 ../../vtunerc.c:506] info: vtuner message! vtunerc: [5207 ../../vtunerc.c:593] info: fake server answer ps fax | grep vtunerc: 5194 pts/4S 0:00 | \_ bash 5210 pts/4S+ 0:00 | \_ [vtunerc.i686] that way it's not good enough for inclusion yet anyway. Markus -- 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 1/1] davinci: dm646x: move vpif related code to driver core header from platform
On Thu, Jun 02, 2011 at 22:51:58, Nori, Sekhar wrote: Hi Mauro, On Fri, May 20, 2011 at 19:28:49, Hadli, Manjunath wrote: move vpif related code for capture and display drivers from dm646x platform header file to vpif.h as these definitions are related to driver code more than the platform or board. Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Will you be taking this patch through your tree? If not, with your ack, I can queue it for inclusion through the ARM tree. Ping :) Thanks, Sekhar --- arch/arm/mach-davinci/include/mach/dm646x.h | 53 +--- drivers/media/video/davinci/vpif.h |1 + drivers/media/video/davinci/vpif_capture.h |2 +- drivers/media/video/davinci/vpif_display.h |1 + include/media/davinci/vpif.h| 73 +++ 5 files changed, 77 insertions(+), 53 deletions(-) create mode 100644 include/media/davinci/vpif.h -- 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: Updates to French scan files
Le 20/06/2011 22:09, Antti Palosaari a écrit : On 06/20/2011 11:04 PM, mossroy wrote: In France, the DVB-T channels are currently moving (because the analog TV is being removed at the same time) The frequencies are modified region by region, with a calendar that started in late 2009, and will end on november 29th 2011 (see http://www.tousaunumerique.fr/ou-et-quand/ ) All the new channels are listed here : http://www.tousaunumerique.fr/professionnels/en-savoir-plus/documentation/categorie-doc/plans-de-frequences/ . The PDF files also lists channels that are planned to be used in the future (but are unused at the moment) Is there already a plan to update the scan files to reflect these changes? Feel free to do that. regards Antti It looks like there is a limited number of frequencies used over the country : http://www.cgvforum.fr/phpBB3/html/faq_tnt.html#recept7 I am lazy so I was wondering why there was one file of frequencies for each town in /usr/share/dvb/dvb-t/. Would it be harmful to have only one list with all those frequencies (there are 57) for all the country? I suppose the DVB-T softwares will take longer to find the channels in all these frequencies, instead of scanning only the ~10 relevant ones. But isn't it what every television does? All the hardware TNT receiver I know scan all the frequencies without knowing in which town you are. Plus it would enable future usage of the currently unused frequencies, without the need to modify the files again I suppose I missed something because that would be too easy ;-) -- 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: RTL2831U driver updates
Thanks. Do you know more about this subject ? We do have specs about the chipset, but http://linuxtv.org/downloads/v4l-dvb-apis/remote_controllers.html#Remote_controllers_Intro only mentions lirc, not rc-core. This is about where my knowledge stops, however. rc-core is only mentioned shortly in: http://linuxtv.org/wiki/index.php/Remote_Controllers Steffen Barszus wrote: 2011/6/21 Jan Hoogenraadjan-conceptro...@hoogenraad.net: and add the IR remote interface, based on the LIRC framework. It actually should yield little code, and mainly requires a) understanding of LIRC and b) comparing code tables to that the in-kernel code tables can be re-used. sorry for the noise , but i guess you mean rc-core not Lirc -- 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 -- Jan Hoogenraad Hoogenraad Interface Services Postbus 2717 3500 GS Utrecht -- 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
Betr: [linux-dvb] Elgato eyetv hybrid (0df9:0018)
-- Oorspronkelijk bericht -- From: Eddie Lania ed...@lania.nl To: linux-...@linuxtv.org Date: Tue, 21 Jun 2011 17:25:02 +0200 Subject: [linux-dvb] Elgato eyetv hybrid (0df9:0018) Reply-To: linux-media@vger.kernel.org Hello, Since a while i am the proud owner of an Elgato Eyetb Hybrid usb tv tuner stick. I tried to get my device, an Elgato eyetev hybrid, to work using the latest drivers from git but it doesn't work (yet). Can somebody tell if this device (usb device 0df9:0018) is/will be supported? From what i found on the internet, the device's specs are: Model: EU 2008 USB Contoller: Empia EM2884 Stereo A/V Decoder: Micronas AVF 49x08 Hybrid Channel Decoder: Micronas DRX-K DRX3926K:A1 0.9.0 Regards, Eddie. ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb I can't find the USB id on the linuxtv list, so I guess your device is not supported yet: http://linuxtv.org/wiki/index.php/DVB-T_USB_Devices Best regards, Cedric -- 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/RFC] fbdev: Add FOURCC-based format configuration API
Hi Geert, Laurent, On 06/21/2011 10:31 PM, Laurent Pinchart wrote: Hi Geert, On Tuesday 21 June 2011 22:49:14 Geert Uytterhoeven wrote: On Tue, Jun 21, 2011 at 17:36, Laurent Pinchart wrote: +The FOURCC-based API replaces format descriptions by four character codes +(FOURCC). FOURCCs are abstract identifiers that uniquely define a format +without explicitly describing it. This is the only API that supports YUV +formats. Drivers are also encouraged to implement the FOURCC-based API for RGB +and grayscale formats. + +Drivers that support the FOURCC-based API report this capability by setting +the FB_CAP_FOURCC bit in the fb_fix_screeninfo capabilities field. + +FOURCC definitions are located in the linux/videodev2.h header. However, and +despite starting with the V4L2_PIX_FMT_prefix, they are not restricted to V4L2 +and don't require usage of the V4L2 subsystem. FOURCC documentation is +available in Documentation/DocBook/v4l/pixfmt.xml. + +To select a format, applications set the FB_VMODE_FOURCC bit in the +fb_var_screeninfo vmode field, and set the fourcc field to the desired FOURCC. +The bits_per_pixel, red, green, blue, transp and nonstd fields must be set to +0 by applications and ignored by drivers. Note that the grayscale and fourcc +fields share the same memory location. Application must thus not set the +grayscale field to 0. These are the only parts I don't like: (ab)using the vmode field (this isn't really a vmode flag), and the union of grayscale and fourcc (avoid unions where possible). I've proposed adding a FB_NONSTD_FORMAT bit to the nonstd field as a FOURCC mode indicator in my initial RFC. Florian Tobias Schandinat wasn't very happy with that, and proposed using the vmode field instead. Given that there's virtually no fbdev documentation, whether the vmode field and/or nonstd field are good fit for a FOURCC mode indicator is subject to interpretation. The reason for my suggestion is that the vmode field is accepted to contain only flags and at least to me there is no hard line what is part of the video mode and what is not. In contrast the nonstd field is already used in a lot of different (incompatible) ways. I think if we only use the nonstd field for handling FOURCC it is likely that some problems will appear. What about storing the FOURCC value in nonstd instead? Wouldn't that be a union of nonstd and fourcc ? :-) FOURCC-based format setting will be a standard fbdev API, I'm not very keen on storing it in the nonstd field without a union. As FOURCC values are always 4 ASCII characters (hence all 4 bytes must be non-zero), I don't think there are any conflicts with existing values of nonstd. To make it even safer and easier to parse, you could set bit 31 of nonstd as a FOURCC indicator. I would then create a union between nonstd and fourcc, and document nonstd as being used for the legacy API only. Most existing drivers use a couple of nonstd bits only. The driver that (ab)uses nonstd the most is pxafb and uses bits 22:0. Bits 31:24 are never used as far as I can tell, so nonstd 0xff00 != 0 could be used as a FOURCC mode test. This assumes that FOURCCs will never have their last character set to '\0'. Is that a safe assumption for the future ? Yes, I think. The information I found indicates that space should be used for padding, so a \0 shouldn't exist. I think using only the nonstd field and requiring applications to check the capabilities would be possible, although not fool proof ;) Great work, Laurent, do you have plans to modify fbset to allow using this format API from the command line? Regards, Florian Tobias Schandinat -- 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
