Re: [PULL] soc-camera: bulk of the v4l2-subdev conversion
On Thursday 27 August 2009 00:44:13 Guennadi Liakhovetski wrote: On Thu, 27 Aug 2009, Hans Verkuil wrote: On Wednesday 26 August 2009 23:55:29 Guennadi Liakhovetski wrote: On Wed, 26 Aug 2009, Mauro Carvalho Chehab wrote: Em Tue, 25 Aug 2009 17:11:26 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu: Hi Mauro Here they come... The first one is a kernel-sync, I skipped two more similar patches for other ARM platforms, because they are not in hg at all. The rest are marked Priority: low as you requested to stress, that they should go in after those three ARM (PXA) patches. I still have a couple more patches, which I will also try to prepare and push for 2.6.32, but let's get these ones first in. Some patches do not pass checkpatch cleanly, but if you check the cumulative diff, it should be clean apart from a couple false positives. The last patch in the series does the clean up. Please pull from http://linuxtv.org/hg/~gliakhovetski/v4l-dvb for the following 35 changesets: [snip] There are some compilation troubles now on x86_64 compilation: /home/v4l/master/v4l/soc_camera_platform.c: In function 'soc_camera_platform_probe': /home/v4l/master/v4l/soc_camera_platform.c:140: warning: cast from pointer to integer of different size /home/v4l/master/v4l/soc_camera.c: In function 'soc_camera_init_i2c': /home/v4l/master/v4l/soc_camera.c:860: warning: cast from pointer to integer of different size I'll take a look later and try to fix. Hm, these are lines like subdev-grp_id = (__u32)icd; I think, grp_id should become unsigned long, Hans? Where and how is grp_id used? This seems to me to be an abuse of this field. It is really not meant to contain a pointer. I can't find any actual use of this field in this driver, so either I'm missing something or this is simply not needed at all. We discussed this before, here's an excerpt from your earlier reply to my mail: quote In fact, what I actually need is to call a specific method, if it is implemented, from one specific subdevice, and get its error code - not from all and not until the first error. I am currently abusing your grp_id for this, but it might eventually be better to add such a wrapper. That's actually what grp_id is intended for (or one of the intended uses at least). /quote I'm pretty sure I didn't realize at the time that you would attempt to store a pointer in grp_id. But, I think, since then I switched to using v4l2_subdev_call() _everywhere_, so, it might well be, that this grp_id can go completely. Not sure off the top of my head though. If you only use v4l2_subdev_call then you do not need to set grp_id at all. So these lines can be removed. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: [PULL] soc-camera: bulk of the v4l2-subdev conversion
On Thu, 27 Aug 2009, Hans Verkuil wrote: On Thursday 27 August 2009 00:44:13 Guennadi Liakhovetski wrote: On Thu, 27 Aug 2009, Hans Verkuil wrote: On Wednesday 26 August 2009 23:55:29 Guennadi Liakhovetski wrote: Hm, these are lines like subdev-grp_id = (__u32)icd; I think, grp_id should become unsigned long, Hans? Where and how is grp_id used? This seems to me to be an abuse of this field. It is really not meant to contain a pointer. I can't find any actual use of this field in this driver, so either I'm missing something or this is simply not needed at all. We discussed this before, here's an excerpt from your earlier reply to my mail: quote In fact, what I actually need is to call a specific method, if it is implemented, from one specific subdevice, and get its error code - not from all and not until the first error. I am currently abusing your grp_id for this, but it might eventually be better to add such a wrapper. That's actually what grp_id is intended for (or one of the intended uses at least). /quote I'm pretty sure I didn't realize at the time that you would attempt to store a pointer in grp_id. Yep, sorry, I didn't mention that. But, I think, since then I switched to using v4l2_subdev_call() _everywhere_, so, it might well be, that this grp_id can go completely. Not sure off the top of my head though. If you only use v4l2_subdev_call then you do not need to set grp_id at all. So these lines can be removed. Yes, certainly looks like you're right. So, would it be enough to push a patch removing these two lines on top of the series? Notice, there are currently no 64-bit platforms, that use soc-camera, so, this bug just adds two compiler warnings for a couple of commits in an unpractical configuration:-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: [PULL] soc-camera: bulk of the v4l2-subdev conversion
On Thursday 27 August 2009 08:36:29 Guennadi Liakhovetski wrote: On Thu, 27 Aug 2009, Hans Verkuil wrote: On Thursday 27 August 2009 00:44:13 Guennadi Liakhovetski wrote: On Thu, 27 Aug 2009, Hans Verkuil wrote: On Wednesday 26 August 2009 23:55:29 Guennadi Liakhovetski wrote: Hm, these are lines like subdev-grp_id = (__u32)icd; I think, grp_id should become unsigned long, Hans? Where and how is grp_id used? This seems to me to be an abuse of this field. It is really not meant to contain a pointer. I can't find any actual use of this field in this driver, so either I'm missing something or this is simply not needed at all. We discussed this before, here's an excerpt from your earlier reply to my mail: quote In fact, what I actually need is to call a specific method, if it is implemented, from one specific subdevice, and get its error code - not from all and not until the first error. I am currently abusing your grp_id for this, but it might eventually be better to add such a wrapper. That's actually what grp_id is intended for (or one of the intended uses at least). /quote I'm pretty sure I didn't realize at the time that you would attempt to store a pointer in grp_id. Yep, sorry, I didn't mention that. But, I think, since then I switched to using v4l2_subdev_call() _everywhere_, so, it might well be, that this grp_id can go completely. Not sure off the top of my head though. If you only use v4l2_subdev_call then you do not need to set grp_id at all. So these lines can be removed. Yes, certainly looks like you're right. So, would it be enough to push a patch removing these two lines on top of the series? Notice, there are currently no 64-bit platforms, that use soc-camera, so, this bug just adds two compiler warnings for a couple of commits in an unpractical configuration:-) Yes, please. It's dead code after all and dead code is bad. And so are unnecessary warnings in a daily build, BTW. Actually, I consider dead code the worst coding sin there is: bugs are easy: it clearly doesn't work, so you know the code is wrong. Missing code is equally easy: the code to handle a particular feature is simply not there. But dead code is deadly since it leads to questions like: Is it really not used or is it used somehow in some subtle manner? Was it intended for some essential feature that is still to be implemented? If so, do we still need to implement that or is it no longer needed? I've had to deal with things like that in the past where the original author was no longer available and I hated it every time that happened. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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] Pixel format definition on the image bus
On Wednesday 26 August 2009 16:39:16 Guennadi Liakhovetski wrote:
Hi all
With the ability to arbitrarily combine (video) data sources and sinks we
have to be able to suitably configure both parties. This includes setting
bus parameters, which is discussed elsewhere, and selecting a data format,
which is discussed in this RFC.
Video data, coming from a source (e.g., a camera sensor) to a sink (e.g.,
a bridge) can be processed in two ways: (1) as raw data, and (2) as
formatted data.
Definition 1: Raw Data Sampling means storing frames, consisting of a
certain number of lines, consisting of a certain number of samples (which
may or may not represent pixels) in memory. Each sample contains a certain
number of bits of useful information, multiple samples can be packed
together according to some rule.
In case (1) the sink has no specific knowledge about the format, so it can
only sample data on its data bus and store it in memory in some specific
manner. This manner is completely defined by the following three
parameters: (a) how many bits are sampled, (b) in which order they will be
stored in memory, (c) how samples have to be packed. To provide such raw
data to the user the bridge driver also has to know what format the data
represents if stored in memory as required by the source.
In case (2) the sink knows this specific format and can handle it
accordingly, e.g., convert to some other format.
It is therefore proposed to describe a data format on-the-bus using the
following parameters:
enum V4L2_DATA_PACKING {
V4L2_DATA_PACKING_NONE = 0,
};
enum V4L2_DATA_ORDER {
V4L2_DATA_ORDER_LE = 0,
V4L2_DATA_ORDER_BE = 1,
};
/**
* struct v4l2_subdev_bus_pixelfmt - Data format on the image bus
* @sourceformat: Format identification for sinks, capable to process this
*specific format
* @pixelformat: Fourcc code...
* @colorspace: and colorspace, that will be obtained if the
data is
*stored in memory in the following way:
* @bits_per_sample: How many bits the bridge has to sample
* @packing: Type of sample-packing, that has to be used
* @order:Sample order when storing in memory
*/
struct v4l2_subdev_bus_pixelfmt {
u32 sourceformat;
u32 pixelformat;
enum v4l2_colorspacecolorspace;
int index;
u8 bits_per_sample;
enum V4L2_DATA_PACKING packing;
enum V4L2_DATA_ORDERorder;
};
The .sourceformat field above is a new enumeration, similar to currently
defined in include/linux/videodev2.h fourcc codes, but combining the
fourcc, bits-per-sample, packing and order information in one. If an
existing Fourcc code already uniquely defines this combination, the new
code might coincide with it. In principle, this code is redundant, because
the data format is completely described by the raw parameters, but it
can be useful for some (simple) source-sink combinations.
The sink driver can then use the following new method from struct
v4l2_subdev_video_ops:
int (*enum_bus_pixelfmt)(struct v4l2_subdev *sd,
const struct v4l2_subdev_bus_pixelfmt **fmt);
to enumerate formats, provided by the source and to decide, which of them
it can support in raw mode, which as formatted data, and which of them it
cannot support at all, e.g., because it does not support the requested
packing type. This enumeration can either take place upon reception of a
S_FMT ioctl, or during probing to build a list of formats, that this
specific source-sink pair can provide to the user.
Comments welcome.
Hi Guennadi,
This seems way too complicated to me. The original approach you took in
soc_camera (just a fourcc code and the colorspace) seems fine to me (and
colorspace is probably not even needed). The sensor supports X formats, the
sink supports Y sensor formats and knows how to map those to the actual
formats as are returned by VIDIOC_ENUM_FMT. So a pointer to a list of supported
fourcc codes is probably all you need.
But I also have other questions that need to be answered:
1) Isn't there a relationship between the supported sensor formats and the
bus configuration? E.g. the davinci dm646x has two bus modes on its capture
port: either embedded syncs or separate syncs. Depending on the mode it can
capture different formats.
2) What will the relationship be between this functionality and how the
enum/try/g/s_fmt subdev ops are currently used? Perhaps we should switch
everything over to this new API? I think there are only three subdev drivers
that use these fmt ops, so it wouldn't be too hard to change them if we decide
to do so.
I'm definitely going to think about this some more when I work on the bus
config RFC this weekend.
Regards,
Hans
--
Hans Verkuil -
Re: [RFC] Pixel format definition on the image bus
On Thu, 27 Aug 2009, Hans Verkuil wrote:
On Wednesday 26 August 2009 16:39:16 Guennadi Liakhovetski wrote:
Hi all
With the ability to arbitrarily combine (video) data sources and sinks we
have to be able to suitably configure both parties. This includes setting
bus parameters, which is discussed elsewhere, and selecting a data format,
which is discussed in this RFC.
Video data, coming from a source (e.g., a camera sensor) to a sink (e.g.,
a bridge) can be processed in two ways: (1) as raw data, and (2) as
formatted data.
Definition 1: Raw Data Sampling means storing frames, consisting of a
certain number of lines, consisting of a certain number of samples (which
may or may not represent pixels) in memory. Each sample contains a certain
number of bits of useful information, multiple samples can be packed
together according to some rule.
In case (1) the sink has no specific knowledge about the format, so it can
only sample data on its data bus and store it in memory in some specific
manner. This manner is completely defined by the following three
parameters: (a) how many bits are sampled, (b) in which order they will be
stored in memory, (c) how samples have to be packed. To provide such raw
data to the user the bridge driver also has to know what format the data
represents if stored in memory as required by the source.
In case (2) the sink knows this specific format and can handle it
accordingly, e.g., convert to some other format.
It is therefore proposed to describe a data format on-the-bus using the
following parameters:
enum V4L2_DATA_PACKING {
V4L2_DATA_PACKING_NONE = 0,
};
enum V4L2_DATA_ORDER {
V4L2_DATA_ORDER_LE = 0,
V4L2_DATA_ORDER_BE = 1,
};
/**
* struct v4l2_subdev_bus_pixelfmt - Data format on the image bus
* @sourceformat: Format identification for sinks, capable to process this
* specific format
* @pixelformat:Fourcc code...
* @colorspace: and colorspace, that will be obtained if the
data is
* stored in memory in the following way:
* @bits_per_sample:How many bits the bridge has to sample
* @packing:Type of sample-packing, that has to be used
* @order: Sample order when storing in memory
*/
struct v4l2_subdev_bus_pixelfmt {
u32 sourceformat;
u32 pixelformat;
enum v4l2_colorspacecolorspace;
int index;
u8 bits_per_sample;
enum V4L2_DATA_PACKING packing;
enum V4L2_DATA_ORDERorder;
};
The .sourceformat field above is a new enumeration, similar to currently
defined in include/linux/videodev2.h fourcc codes, but combining the
fourcc, bits-per-sample, packing and order information in one. If an
existing Fourcc code already uniquely defines this combination, the new
code might coincide with it. In principle, this code is redundant, because
the data format is completely described by the raw parameters, but it
can be useful for some (simple) source-sink combinations.
The sink driver can then use the following new method from struct
v4l2_subdev_video_ops:
int (*enum_bus_pixelfmt)(struct v4l2_subdev *sd,
const struct v4l2_subdev_bus_pixelfmt **fmt);
to enumerate formats, provided by the source and to decide, which of them
it can support in raw mode, which as formatted data, and which of them it
cannot support at all, e.g., because it does not support the requested
packing type. This enumeration can either take place upon reception of a
S_FMT ioctl, or during probing to build a list of formats, that this
specific source-sink pair can provide to the user.
Comments welcome.
Hi Guennadi,
This seems way too complicated to me. The original approach you took in
soc_camera (just a fourcc code and the colorspace) seems fine to me (and
colorspace is probably not even needed). The sensor supports X formats, the
sink supports Y sensor formats and knows how to map those to the actual
formats as are returned by VIDIOC_ENUM_FMT. So a pointer to a list of
supported
fourcc codes is probably all you need.
Unfortunately, even the current soc-camera approach with its
format-enumeration and -conversion API is not enough. As I explained
above, there are two ways you can handle source's data: cooked and
raw. The cooked way is simple - the sink knows exactly this specific
format and knows how to deal with it. Every sink has a final number of
such natively supported formats, so, that's just a switch-case statement
in each sink driver, that is specific to each sink hardware, and that you
cannot avoid.
It's the raw or pass-through mode that is difficult. It is used, when
the sink does not have any specific knowledge about this format, but can
[RFC] Infrared Keycode standardization
After years of analyzing the existing code and receiving/merging patches related to IR, and taking a looking at the current scenario, it is clear to me that something need to be done, in order to have some standard way to map and to give precise key meanings for each used media keycode found on include/linux/input.h. Just as an example, I've parsed the bigger keymap file we have (linux/media/common/ir-common.c). Most IR's have less than 40 keys, most are common between several different models. Yet, we've got almost 500 different mappings there (and I removed from my parser all the obvious keys that there weren't any comment about what is labeled for that key on the IR). The same key name is mapped differently, depending only at the wish of the patch author, as shown at: http://linuxtv.org/wiki/index.php/Ir-common.c It doesn't come by surprise, but currently, almost all media player applications don't care to properly map all those keys. I've tried to find comments and/or descriptions about each media keys defined at input.h without success. Just a few keys are commented at the file itself. (or maybe I've just seek them at the wrong places). So, I took the initiative of doing a proposition for standardizing those keys at: http://linuxtv.org/wiki/index.php/Proposal While I tried to use the most common binding for a key, sometimes the commonly used one is so weird that I've used a different key mapping. Please, don't take it as a finished proposal. For sure we need to adjust it. Being it at wiki provides a way for people to edit, add comments and propose additional keycode matches. Also, there are several keys found on just one IR that didn't match any existing keycode. So, I just decided to keep those outside the table, for now, to focus on the mostly used ones. That's said, please review my proposal. Feel free to update the proposal and the current status if you think it is pertinent for this discussion. I'm not currently proposing to create any new keycode, but it probably makes sense to create a few ones, like KEY_PIP (for picture in picture). If we can go to a common sense, I intend to add it into a chapter at V4L2 API, in order to be used by both driver and userspace developers, submit some patches to fix some mappings and to add the proper comments to input.h. Comments? 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] Pixel format definition on the image bus
On Thu, 27 Aug 2009, Hans Verkuil wrote:
On Wednesday 26 August 2009 16:39:16 Guennadi Liakhovetski wrote:
Hi all
With the ability to arbitrarily combine (video) data sources and sinks
we
have to be able to suitably configure both parties. This includes
setting
bus parameters, which is discussed elsewhere, and selecting a data
format,
which is discussed in this RFC.
Video data, coming from a source (e.g., a camera sensor) to a sink
(e.g.,
a bridge) can be processed in two ways: (1) as raw data, and (2) as
formatted data.
Definition 1: Raw Data Sampling means storing frames, consisting of a
certain number of lines, consisting of a certain number of samples
(which
may or may not represent pixels) in memory. Each sample contains a
certain
number of bits of useful information, multiple samples can be packed
together according to some rule.
In case (1) the sink has no specific knowledge about the format, so it
can
only sample data on its data bus and store it in memory in some
specific
manner. This manner is completely defined by the following three
parameters: (a) how many bits are sampled, (b) in which order they
will be
stored in memory, (c) how samples have to be packed. To provide such
raw
data to the user the bridge driver also has to know what format the
data
represents if stored in memory as required by the source.
In case (2) the sink knows this specific format and can handle it
accordingly, e.g., convert to some other format.
It is therefore proposed to describe a data format on-the-bus using
the
following parameters:
enum V4L2_DATA_PACKING {
V4L2_DATA_PACKING_NONE = 0,
};
enum V4L2_DATA_ORDER {
V4L2_DATA_ORDER_LE = 0,
V4L2_DATA_ORDER_BE = 1,
};
/**
* struct v4l2_subdev_bus_pixelfmt - Data format on the image bus
* @sourceformat: Format identification for sinks, capable to process
this
* specific format
* @pixelformat: Fourcc code...
* @colorspace:and colorspace, that will be obtained if the
data is
* stored in memory in the following way:
* @bits_per_sample: How many bits the bridge has to sample
* @packing: Type of sample-packing, that has to be used
* @order: Sample order when storing in memory
*/
struct v4l2_subdev_bus_pixelfmt {
u32 sourceformat;
u32 pixelformat;
enum v4l2_colorspacecolorspace;
int index;
u8 bits_per_sample;
enum V4L2_DATA_PACKING packing;
enum V4L2_DATA_ORDERorder;
};
The .sourceformat field above is a new enumeration, similar to
currently
defined in include/linux/videodev2.h fourcc codes, but combining the
fourcc, bits-per-sample, packing and order information in one. If an
existing Fourcc code already uniquely defines this combination, the
new
code might coincide with it. In principle, this code is redundant,
because
the data format is completely described by the raw parameters, but
it
can be useful for some (simple) source-sink combinations.
The sink driver can then use the following new method from struct
v4l2_subdev_video_ops:
int (*enum_bus_pixelfmt)(struct v4l2_subdev *sd,
const struct v4l2_subdev_bus_pixelfmt **fmt);
to enumerate formats, provided by the source and to decide, which of
them
it can support in raw mode, which as formatted data, and which of them
it
cannot support at all, e.g., because it does not support the requested
packing type. This enumeration can either take place upon reception of
a
S_FMT ioctl, or during probing to build a list of formats, that this
specific source-sink pair can provide to the user.
Comments welcome.
Hi Guennadi,
This seems way too complicated to me. The original approach you took in
soc_camera (just a fourcc code and the colorspace) seems fine to me (and
colorspace is probably not even needed). The sensor supports X formats,
the
sink supports Y sensor formats and knows how to map those to the actual
formats as are returned by VIDIOC_ENUM_FMT. So a pointer to a list of
supported
fourcc codes is probably all you need.
Unfortunately, even the current soc-camera approach with its
format-enumeration and -conversion API is not enough. As I explained
above, there are two ways you can handle source's data: cooked and
raw. The cooked way is simple - the sink knows exactly this specific
format and knows how to deal with it. Every sink has a final number of
such natively supported formats, so, that's just a switch-case statement
in each sink driver, that is specific to each sink hardware, and that you
cannot avoid.
It's the raw or pass-through mode that is difficult. It is used, when
the sink does not have any specific knowledge about this format, but can
pack data into RAM in some way, or,
Re: [RFC] Pixel format definition on the image bus
On Thu, 27 Aug 2009, Hans Verkuil wrote: Unfortunately, even the current soc-camera approach with its format-enumeration and -conversion API is not enough. As I explained above, there are two ways you can handle source's data: cooked and raw. The cooked way is simple - the sink knows exactly this specific format and knows how to deal with it. Every sink has a final number of such natively supported formats, so, that's just a switch-case statement in each sink driver, that is specific to each sink hardware, and that you cannot avoid. It's the raw or pass-through mode that is difficult. It is used, when the sink does not have any specific knowledge about this format, but can pack data into RAM in some way, or, hopefully, in a number of ways, among which we can choose. The source knows what data it is delivering, and, in principle, how this data has to be packed in RAM to provide some meaningful user format. Now, we have to pass this information on to the sink driver to tell it if you configure the source to deliver the raw format X, and then configure your bus in a way Y and pack the data into RAM in a way Z, you get as RAM user format W. So, my proposal is - during probing, the sink enumerates all raw formats, provided by the source, accepts those formats, that it can process natively (cooked mode), and verifies if it can be configured to bus configuration Y and can perform packing Z, if so, it adds format W to the list of supported formats. Do you see an easier way to do this? I'm currently trying to port one driver combination to this scheme, I'll post a patch, hopefully, later today. I'm not so keen on attempting to negotiate things that probably are impossible to negotiate anyway. (You may have noticed that before :-) ) I bought your argument about subtle image corruption that might be difficult to debug back to a wrongly chosen signal polarity and / or sensing edge. Now, what's your argument for this one apart from being not so keen? Being not keen doesn't seem a sufficient argument to me for turning platform data into trash-bins. Example: currently a combination SuperH CEU platform with a OV772x camera sensor connected can provide 11 output formats. There are at least two such boards currently in the mainline with the same bus configuration. Do you want to exactly reproduce these 11 entries in these two boards? What about other boards? One approach would be to make this mapping part of the platform data that is passed to the bridge driver. For a 'normal' PCI or USB driver information like this would be contained in the bridge driver. Here you have a generic bridge driver intended to work with different SoCs, so now that information has to move to the platform data. That's the only place where you know exactly how to setup these things. So you would end up with a list of config items: user fourcc, bridge fourcc, sensor fourcc, bus config And the platform data of each sensor device would have such a list. So the bridge driver knows that VIDIOC_ENUMFMT can give user fourcc back to the user, and if the user selects that, then it has to setup the bridge using bridge fourcc and the sensor using sensor fourcc, and the bus as bus config. This is just a high level view as I don't have time to go into this in detail, but I think this is a reasonable approach. It's really no different to what the PCI and USB drivers are doing, except formalized for the generic case. Please, give me a valid reason, why this cannot be auto-enumerated. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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] Pixel format definition on the image bus
On Thu, 27 Aug 2009, Hans Verkuil wrote: Unfortunately, even the current soc-camera approach with its format-enumeration and -conversion API is not enough. As I explained above, there are two ways you can handle source's data: cooked and raw. The cooked way is simple - the sink knows exactly this specific format and knows how to deal with it. Every sink has a final number of such natively supported formats, so, that's just a switch-case statement in each sink driver, that is specific to each sink hardware, and that you cannot avoid. It's the raw or pass-through mode that is difficult. It is used, when the sink does not have any specific knowledge about this format, but can pack data into RAM in some way, or, hopefully, in a number of ways, among which we can choose. The source knows what data it is delivering, and, in principle, how this data has to be packed in RAM to provide some meaningful user format. Now, we have to pass this information on to the sink driver to tell it if you configure the source to deliver the raw format X, and then configure your bus in a way Y and pack the data into RAM in a way Z, you get as RAM user format W. So, my proposal is - during probing, the sink enumerates all raw formats, provided by the source, accepts those formats, that it can process natively (cooked mode), and verifies if it can be configured to bus configuration Y and can perform packing Z, if so, it adds format W to the list of supported formats. Do you see an easier way to do this? I'm currently trying to port one driver combination to this scheme, I'll post a patch, hopefully, later today. I'm not so keen on attempting to negotiate things that probably are impossible to negotiate anyway. (You may have noticed that before :-) ) I bought your argument about subtle image corruption that might be difficult to debug back to a wrongly chosen signal polarity and / or sensing edge. Now, what's your argument for this one apart from being not so keen? Being not keen doesn't seem a sufficient argument to me for turning platform data into trash-bins. Example: currently a combination SuperH CEU platform with a OV772x camera sensor connected can provide 11 output formats. There are at least two such boards currently in the mainline with the same bus configuration. Do you want to exactly reproduce these 11 entries in these two boards? What about other boards? One approach would be to make this mapping part of the platform data that is passed to the bridge driver. For a 'normal' PCI or USB driver information like this would be contained in the bridge driver. Here you have a generic bridge driver intended to work with different SoCs, so now that information has to move to the platform data. That's the only place where you know exactly how to setup these things. So you would end up with a list of config items: user fourcc, bridge fourcc, sensor fourcc, bus config And the platform data of each sensor device would have such a list. So the bridge driver knows that VIDIOC_ENUMFMT can give user fourcc back to the user, and if the user selects that, then it has to setup the bridge using bridge fourcc and the sensor using sensor fourcc, and the bus as bus config. This is just a high level view as I don't have time to go into this in detail, but I think this is a reasonable approach. It's really no different to what the PCI and USB drivers are doing, except formalized for the generic case. Please, give me a valid reason, why this cannot be auto-enumerated. For example a sensor connected to an fpga (doing e.g. color space conversion or some other type of image processing/image improvement) which in turn is connected to the bridge. How you setup the sensor and how you setup the bridge might not have an obvious 1-to-1 mapping. While I have not seen setups like this for sensors, I have seen them for video encoder devices. You assume that a sensor is connected directly to a bridge, but that assumption is simply not true. There may be all sorts of ICs in between. One alternative is to have two approaches: a simple one where you just try to match what the sensor can do and what the bridge can accept, and one where you can override it from the platform data. The latter does not actually have to be implemented as long as there are no boards that need that, but it should be designed in such a way that it is easy to implement it later. It's my opinion that we have to be careful in trying to be too intelligent. There is simply too much variation in hardware out there to ever hope to be able to do that. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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] Pixel format definition on the image bus
On Thu, 27 Aug 2009, Hans Verkuil wrote: For example a sensor connected to an fpga (doing e.g. color space conversion or some other type of image processing/image improvement) which in turn is connected to the bridge. How you setup the sensor and how you setup the bridge might not have an obvious 1-to-1 mapping. While I have not seen setups like this for sensors, I have seen them for video encoder devices. You assume that a sensor is connected directly to a bridge, but that assumption is simply not true. There may be all sorts of ICs in between. No, I do not assume that, that's why in my original RFC I used source and sink instead of camera and SoC. In your example you your FPGA is a subdev to the SoC, and the sensor is a subdev to FPGA, right? So, what stops you from applying my format enumeration twice? Say, first the FPGA enumerates sensor formats and synthesises a list of output formats - again, as source formats, not user formats, because the data is going to be transferred to the host over the image bus, right? It would be a different configuration if you first transfer the data from FPGA to RAM and then let your SoC camera host take the data from there. That would be a different configuration for the host. So, I don't see how your example requires platform data. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
Units in V4L2 controls
Hi, quoting V4L2 spec: http://v4l2spec.bytesex.org/spec/r13317.htm __s32 step [...] Generally drivers should not scale hardware control values. It may be necessary for example when the name or id imply a particular unit and the hardware actually accepts only multiples of said unit. If so, drivers must take care values are properly rounded when scaling, such that errors will not accumulate on repeated read-write cycles. I'm wondering what that particular unit means. Is it OK to name V4L2_CID_EXPOSURE to Exposure time [us] and then use microseconds for exposure time, even if HW supports only image row granularity (rolling shutter)? If not, how should the driver report to user program the actual exposure time (necessary eg. for 50 Hz/60 Hz flicker elimination). What about flash timeout, we have here a circuit which supports only 50, 100, 200, 400, etc. milliseconds. I report step to be 50 ms and then round the user setting to the closest value available. User program could query the actual value used with VIDIOC_G_CTRL. The same problem holds for other controls, at least we'd like to use exposure value (EV) units for gain, etc. - Tuukka -- 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] Pixel format definition on the image bus
To help discussion a bit, here's a current example implementation of the
imagebus interface, still working to provide a working example.
diff --git a/drivers/media/video/v4l2-imagebus.c
b/drivers/media/video/v4l2-imagebus.c
new file mode 100644
index 000..d7ddf93
--- /dev/null
+++ b/drivers/media/video/v4l2-imagebus.c
@@ -0,0 +1,142 @@
+/*
+ * Image Bus API
+ *
+ * Copyright (C) 2009, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+
+#include media/v4l2-device.h
+#include media/v4l2-imagebus.h
+
+static const struct v4l2_imgbus_pixelfmt imgbus_fmt[] = {
+ [V4L2_IMGBUS_FMT_YUYV] = {
+ .rawformat = V4L2_PIX_FMT_YUYV,
+ .colorspace = V4L2_COLORSPACE_JPEG,
+ .bits_per_sample= 8,
+ .packing= V4L2_DATA_PACKING_2X8,
+ .order = V4L2_DATA_ORDER_LE,
+ }, [V4L2_IMGBUS_FMT_YVYU] = {
+ .rawformat = V4L2_PIX_FMT_YVYU,
+ .colorspace = V4L2_COLORSPACE_JPEG,
+ .bits_per_sample= 8,
+ .packing= V4L2_DATA_PACKING_2X8,
+ .order = V4L2_DATA_ORDER_LE,
+ }, [V4L2_IMGBUS_FMT_UYVY] = {
+ .rawformat = V4L2_PIX_FMT_UYVY,
+ .colorspace = V4L2_COLORSPACE_JPEG,
+ .bits_per_sample= 8,
+ .packing= V4L2_DATA_PACKING_2X8,
+ .order = V4L2_DATA_ORDER_LE,
+ }, [V4L2_IMGBUS_FMT_VYUY] = {
+ .rawformat = V4L2_PIX_FMT_VYUY,
+ .colorspace = V4L2_COLORSPACE_JPEG,
+ .bits_per_sample= 8,
+ .packing= V4L2_DATA_PACKING_2X8,
+ .order = V4L2_DATA_ORDER_LE,
+ }, [V4L2_IMGBUS_FMT_VYUY_SMPTE170M_8] = {
+ .rawformat = V4L2_PIX_FMT_VYUY,
+ .colorspace = V4L2_COLORSPACE_SMPTE170M,
+ .bits_per_sample= 8,
+ .packing= V4L2_DATA_PACKING_2X8,
+ .order = V4L2_DATA_ORDER_LE,
+ }, [V4L2_IMGBUS_FMT_VYUY_SMPTE170M_16] = {
+ .rawformat = V4L2_PIX_FMT_VYUY,
+ .colorspace = V4L2_COLORSPACE_SMPTE170M,
+ .bits_per_sample= 16,
+ .packing= V4L2_DATA_PACKING_NONE,
+ .order = V4L2_DATA_ORDER_LE,
+ }, [V4L2_IMGBUS_FMT_RGB555] = {
+ .rawformat = V4L2_PIX_FMT_RGB555,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ .bits_per_sample= 8,
+ .packing= V4L2_DATA_PACKING_2X8,
+ .order = V4L2_DATA_ORDER_LE,
+ }, [V4L2_IMGBUS_FMT_RGB555X] = {
+ .rawformat = V4L2_PIX_FMT_RGB555X,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ .bits_per_sample= 8,
+ .packing= V4L2_DATA_PACKING_2X8,
+ .order = V4L2_DATA_ORDER_LE,
+ }, [V4L2_IMGBUS_FMT_RGB565] = {
+ .rawformat = V4L2_PIX_FMT_RGB565,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ .bits_per_sample= 8,
+ .packing= V4L2_DATA_PACKING_2X8,
+ .order = V4L2_DATA_ORDER_LE,
+ }, [V4L2_IMGBUS_FMT_RGB565X] = {
+ .rawformat = V4L2_PIX_FMT_RGB565X,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ .bits_per_sample= 8,
+ .packing= V4L2_DATA_PACKING_2X8,
+ .order = V4L2_DATA_ORDER_LE,
+ }, [V4L2_IMGBUS_FMT_SBGGR8] = {
+ .rawformat = V4L2_PIX_FMT_SBGGR8,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ .bits_per_sample= 8,
+ .packing= V4L2_DATA_PACKING_NONE,
+ .order = V4L2_DATA_ORDER_LE,
+ }, [V4L2_IMGBUS_FMT_SGBRG8] = {
+ .rawformat = V4L2_PIX_FMT_SGBRG8,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ .bits_per_sample= 8,
+ .packing= V4L2_DATA_PACKING_NONE,
+ .order = V4L2_DATA_ORDER_LE,
+ }, [V4L2_IMGBUS_FMT_SGRBG8] = {
+ .rawformat =
Re: [linux-dvb] Can ir polling be turned off in cx88 module for Leadtek 1000DTV card?
On Wed, 2009-08-26 at 22:52 -0700, Dan Taylor wrote: Trent Piepho wrote: On Wed, 26 Aug 2009, Andy Walls wrote: On Wed, 2009-08-26 at 07:33 -0700, Dalton Harvie wrote: If there isn't, would it be a good idea? Maybe. Thanks for any help. Try this. It adds a module option noir that accepts an array of int's. For a 0, that card's IR is set up as normal; for a 1, that card's IR is not initialized. # modprobe cx88 noir=1,1 I think this is a good idea. I was going to do someting similar to stop the excessive irqs from my cx88 cards, which don't even have remote receivers. I haven't tried, but maybe it is possible to only turn on polling when the event device is opened. Excellent idea. I did something similar for a pseudo-SCSI device, where I only polled if there was a command outstanding. If no one else wants to take it on, I have a pcHDTV-3000 and -5000 and can get a Leadtek something to work with. I don't have any hardware that uses the cx88 driver, so I'm certainly not the right person to muck with it. Have at it! Regards, Andy -- 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
Compile modules on 64-bit Linux kernel system for 686 Linux kernel
Hi guys, ( please CC ) I am running Debian Sid/unstable with a 32-bit userspace with a 64-bit kernel [1]. I want to compile the v4l-dvb modules for a 686 kernel [2] on this system. I installed the header files for the 686 kernel [3], but running $ ARCH=686 make make -C /tmp/v4l-dvb/v4l make[1]: Entering directory `/tmp/v4l-dvb/v4l' perl scripts/make_config_compat.pl /lib/modules/2.6.30-1-amd64/source ./.myconfig ./config-compat.h creating symbolic links... make -C firmware prep make[2]: Entering directory `/tmp/v4l-dvb/v4l/firmware' make[2]: Leaving directory `/tmp/v4l-dvb/v4l/firmware' make -C firmware make[2]: Entering directory `/tmp/v4l-dvb/v4l/firmware' CC ihex2fw Generating vicam/firmware.fw Generating dabusb/firmware.fw Generating dabusb/bitstream.bin Generating ttusb-budget/dspbootcode.bin Generating cpia2/stv0672_vp4.bin Generating av7110/bootcode.bin make[2]: Leaving directory `/tmp/v4l-dvb/v4l/firmware' Kernel build directory is /lib/modules/2.6.30-1-amd64/build make -C /lib/modules/2.6.30-1-amd64/build SUBDIRS=/tmp/v4l-dvb/v4l modules make[2]: Entering directory `/usr/src/linux-headers-2.6.30-1-amd64' […] still uses the 64-bit modules in /lib/modules/2.6.30-1-amd64 and the files in /usr/src/linux-headers-2.6.30-1-amd64. I do not even know if this is the correct way. Can someone of you please enlighten me? Thanks, Paul [1] http://packages.debian.org/de/sid/linux-image-2.6.30-1-amd64 [2] http://packages.debian.org/de/sid/linux-image-2.6.30-1-686 [3] http://packages.debian.org/de/sid/linux-headers-2.6.30-1-686 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Compile modules on 64-bit Linux kernel system for 686 Linux kernel
Em Thu, 27 Aug 2009 13:28:57 +0200 Paul Menzel paulepan...@users.sourceforge.net escreveu: Hi guys, ( please CC ) I am running Debian Sid/unstable with a 32-bit userspace with a 64-bit kernel [1]. I want to compile the v4l-dvb modules for a 686 kernel [2] on this system. I installed the header files for the 686 kernel [3], but running $ ARCH=686 make make -C /tmp/v4l-dvb/v4l make[1]: Entering directory `/tmp/v4l-dvb/v4l' perl scripts/make_config_compat.pl /lib/modules/2.6.30-1-amd64/source ./.myconfig ./config-compat.h creating symbolic links... make -C firmware prep make[2]: Entering directory `/tmp/v4l-dvb/v4l/firmware' make[2]: Leaving directory `/tmp/v4l-dvb/v4l/firmware' make -C firmware make[2]: Entering directory `/tmp/v4l-dvb/v4l/firmware' CC ihex2fw Generating vicam/firmware.fw Generating dabusb/firmware.fw Generating dabusb/bitstream.bin Generating ttusb-budget/dspbootcode.bin Generating cpia2/stv0672_vp4.bin Generating av7110/bootcode.bin make[2]: Leaving directory `/tmp/v4l-dvb/v4l/firmware' Kernel build directory is /lib/modules/2.6.30-1-amd64/build make -C /lib/modules/2.6.30-1-amd64/build SUBDIRS=/tmp/v4l-dvb/v4l modules make[2]: Entering directory `/usr/src/linux-headers-2.6.30-1-amd64' […] still uses the 64-bit modules in /lib/modules/2.6.30-1-amd64 and the files in /usr/src/linux-headers-2.6.30-1-amd64. I do not even know if this is the correct way. Can someone of you please enlighten me? This is not the correct way. You'll need to also point where do you expect it to get the headers: This should do the trick: make ARCH=i386 release DIR=directory_name make ARCH=i386 allmodconfig make ARCH=i386 Thanks, Paul [1] http://packages.debian.org/de/sid/linux-image-2.6.30-1-amd64 [2] http://packages.debian.org/de/sid/linux-image-2.6.30-1-686 [3] http://packages.debian.org/de/sid/linux-headers-2.6.30-1-686 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: [linux-dvb] Unsupported devices
Hi, i have the same problem with a Compro T750. Maybe Vmware can emulate a pci device for the guest OS, and pass all the traffic to the real device. -Original Message- From: E.T. Anderson firebringe...@hotmail.com To: linux-...@linuxtv.org Sent: Tue, Aug 25, 2009 4:21 am Subject: [linux-dvb] Unsupported devices I currently own both an Artec T14a tuner and OnAir HDTV-GT tuner. Both of these are ATSC tuners (I'm in the US). I'm not sure what I can do to help, but I'll put myself out there. E.T. Anderson firebringe...@hotmail.com (253) 347 - 5903___ 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 ___ 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 -- 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] Add support for RoverMedia TV Link Pro FM
Hello.
This patch add support for RoverMedia TV Link Pro FM card based on saa7134.
Signed-off-by: Eugene Yudin eugene.yu...@gmail.com
Best Regards, Eugene.
diff -uprN a/linux/Documentation/video4linux/CARDLIST.saa7134
b/linux/Documentation/video4linux/CARDLIST.saa7134
--- a/linux/Documentation/video4linux/CARDLIST.saa7134 2009-08-26
12:07:09.0 +0400
+++ b/linux/Documentation/video4linux/CARDLIST.saa7134 2009-08-27
20:59:24.946147754 +0400
@@ -168,3 +168,4 @@
167 - Beholder BeholdTV 609 RDS[5ace:6092]
168 - Beholder BeholdTV 609 RDS[5ace:6093]
169 - Compro VideoMate S350/S300 [185b:c900]
+170 - RoverMedia TV Link Pro FM[19d1:0138]
diff -uprN a/linux/drivers/media/video/saa7134/saa7134-cards.c
b/linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c 2009-08-27
20:27:10.0 +0400
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c 2009-08-27
20:37:32.336277639 +0400
@@ -5182,6 +5182,55 @@ struct saa7134_board saa7134_boards[] =
.amux = LINE1
} },
},
+ [SAA7134_BOARD_ROVERMEDIA_LINK_PRO_FM] = {
+ /* Eugene Yudin eugene.yu...@gmail.com */
+ .name = RoverMedia TV Link Pro FM,
+ .audio_clock= 0x0020,
+ .tuner_type = TUNER_PHILIPS_FQ1216ME,
+ .radio_type = UNSET,
+ .tuner_addr = ADDR_UNSET,
+ .radio_addr = ADDR_UNSET,
+
+ .gpiomask = 0xe000,
+ .inputs = {{
+ .name = name_tv,
+ .vmux = 1,
+ .amux = TV,
+ .gpio = 0x8000,
+ .tv = 1,
+ },{
+ .name = name_tv_mono,
+ .vmux = 1,
+ .amux = LINE2,
+ .gpio = 0x,
+ .tv = 1,
+ },{
+ .name = name_comp1,
+ .vmux = 0,
+ .amux = LINE2,
+ .gpio = 0x4000,
+ },{
+ .name = name_comp2,
+ .vmux = 3,
+ .amux = LINE2,
+ .gpio = 0x4000,
+ },{
+ .name = name_svideo,
+ .vmux = 8,
+ .amux = LINE2,
+ .gpio = 0x4000,
+ }},
+ .radio = {
+ .name = name_radio,
+ .amux = LINE2,
+ .gpio = 0x2000,
+ },
+ .mute = {
+ .name = name_mute,
+ .amux = TV,
+ .gpio = 0x8000,
+ },
+ },
};
const unsigned int saa7134_bcount = ARRAY_SIZE(saa7134_boards);
@@ -6296,6 +6345,12 @@ struct pci_device_id saa7134_pci_tbl[] =
.subdevice= 0xc900,
.driver_data = SAA7134_BOARD_VIDEOMATE_S350,
}, {
+ .vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7134,
+ .subvendor= 0x19d1, /* RoverMedia */
+ .subdevice= 0x0138, /* LifeView FlyTV Prime30 OEM */
+ .driver_data = SAA7134_BOARD_ROVERMEDIA_LINK_PRO_FM,
+ }, {
/* --- boards without eeprom + subsystem ID --- */
.vendor = PCI_VENDOR_ID_PHILIPS,
.device = PCI_DEVICE_ID_PHILIPS_SAA7134,
@@ -6656,6 +6711,7 @@ int saa7134_board_init1(struct saa7134_d
case SAA7134_BOARD_REAL_ANGEL_220:
case SAA7134_BOARD_KWORLD_PLUS_TV_ANALOG:
case SAA7134_BOARD_AVERMEDIA_GO_007_FM_PLUS:
+ case SAA7134_BOARD_ROVERMEDIA_LINK_PRO_FM:
dev-has_remote = SAA7134_REMOTE_GPIO;
break;
case SAA7134_BOARD_FLYDVBS_LR300:
diff -uprN a/linux/drivers/media/video/saa7134/saa7134-input.c
b/linux/drivers/media/video/saa7134/saa7134-input.c
--- a/linux/drivers/media/video/saa7134/saa7134-input.c 2009-08-26
12:07:11.0 +0400
+++ b/linux/drivers/media/video/saa7134/saa7134-input.c 2009-08-27
19:49:42.0 +0400
@@ -456,6 +456,7 @@ int saa7134_input_init1(struct saa7134_d
case SAA7134_BOARD_FLYVIDEO3000:
case SAA7134_BOARD_FLYTVPLATINUM_FM:
case SAA7134_BOARD_FLYTVPLATINUM_MINI2:
+ case SAA7134_BOARD_ROVERMEDIA_LINK_PRO_FM:
ir_codes = ir_codes_flyvideo;
mask_keycode = 0xEC0;
mask_keydown = 0x004;
diff -uprN a/linux/drivers/media/video/saa7134/saa7134.h
b/linux/drivers/media/video/saa7134/saa7134.h
--- a/linux/drivers/media/video/saa7134/saa7134.h 2009-08-26
12:07:11.0 +0400
+++
Re: [RFC] Infrared Keycode standardization
Mauro Carvalho Chehab wrote: Hi Mauro, All Would it be an alternative to let lirc do the mapping and just let the driver pass the codes of the remote to the event port. That way you do not need to patch the kernel for each new card/remote that comes out. Just release a different map file for lirc for the remote of choice. Peter After years of analyzing the existing code and receiving/merging patches related to IR, and taking a looking at the current scenario, it is clear to me that something need to be done, in order to have some standard way to map and to give precise key meanings for each used media keycode found on include/linux/input.h. Just as an example, I've parsed the bigger keymap file we have (linux/media/common/ir-common.c). Most IR's have less than 40 keys, most are common between several different models. Yet, we've got almost 500 different mappings there (and I removed from my parser all the obvious keys that there weren't any comment about what is labeled for that key on the IR). The same key name is mapped differently, depending only at the wish of the patch author, as shown at: http://linuxtv.org/wiki/index.php/Ir-common.c It doesn't come by surprise, but currently, almost all media player applications don't care to properly map all those keys. I've tried to find comments and/or descriptions about each media keys defined at input.h without success. Just a few keys are commented at the file itself. (or maybe I've just seek them at the wrong places). So, I took the initiative of doing a proposition for standardizing those keys at: http://linuxtv.org/wiki/index.php/Proposal While I tried to use the most common binding for a key, sometimes the commonly used one is so weird that I've used a different key mapping. Please, don't take it as a finished proposal. For sure we need to adjust it. Being it at wiki provides a way for people to edit, add comments and propose additional keycode matches. Also, there are several keys found on just one IR that didn't match any existing keycode. So, I just decided to keep those outside the table, for now, to focus on the mostly used ones. That's said, please review my proposal. Feel free to update the proposal and the current status if you think it is pertinent for this discussion. I'm not currently proposing to create any new keycode, but it probably makes sense to create a few ones, like KEY_PIP (for picture in picture). If we can go to a common sense, I intend to add it into a chapter at V4L2 API, in order to be used by both driver and userspace developers, submit some patches to fix some mappings and to add the proper comments to input.h. Comments? 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: [RFC] Infrared Keycode standardization
On Aug 27, 2009, at 1:06 PM, Peter Brouwer wrote: Mauro Carvalho Chehab wrote: Hi Mauro, All Would it be an alternative to let lirc do the mapping and just let the driver pass the codes of the remote to the event port. That way you do not need to patch the kernel for each new card/ remote that comes out. Just release a different map file for lirc for the remote of choice. But even if lirc is opening the event device, its worth standardizing what keys send which event code. I still need to read over the entire proposal, as well as some earlier related threads, been busy with other things. Sidenote: someone (me) also needs to stop sloughing and submit lirc drivers upstream again... After years of analyzing the existing code and receiving/merging patches related to IR, and taking a looking at the current scenario, it is clear to me that something need to be done, in order to have some standard way to map and to give precise key meanings for each used media keycode found on include/linux/input.h. ... -- Jarod Wilson ja...@wilsonet.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] Infrared Keycode standardization
On Thu, Aug 27, 2009 at 1:06 PM, Peter Brouwerpb.mailli...@googlemail.com wrote: Mauro Carvalho Chehab wrote: Hi Mauro, All Would it be an alternative to let lirc do the mapping and just let the driver pass the codes of the remote to the event port. That way you do not need to patch the kernel for each new card/remote that comes out. Just release a different map file for lirc for the remote of choice. Peter The biggest challenge with that approach is that lirc is still maintained out-of-kernel, and the inputdev solution does not require lirc at all (which is good for inexperienced end users who want their product to just work). Keeping the remote definitions in-kernel also helps developers adding support for new products, since they can be sure that both the device and its remote will appear in the same kernel version (they are inherently in-sync compared to cases where the distribution upgrades the kernel but not necessarily the lircd version they bundle). The other big issue is that right now remotes get associated automaticallywith products as part of the device profile. While this has the disadvantage that there is not a uniform mechanism to specify a different remote than the one that ships with the product, it does have the advantage of the product working out-of-the-box with whatever remote it came with. It's a usability issue, but what I would consider a pretty important one. That said, if we had a way to have some sort of remote control signature that can be associated with lirc remote control definitions, which can be referenced in-kernel, that would solve the above mentioned problem of making the product work by default with the remote it shipped with. 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
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: 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:Thu Aug 27 19:00:06 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12560:135c140b71de gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-rc5-armv5: OK linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: OK linux-2.6.29.1-armv5-ixp: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-rc5-armv5-ixp: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-rc5-armv5-omap2: OK linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-rc5-i686: OK linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-rc5-m32r: OK linux-2.6.30-mips: ERRORS linux-2.6.31-rc5-mips: OK linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-rc5-powerpc64: WARNINGS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.11-x86_64: ERRORS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: WARNINGS linux-2.6.28-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-rc5-x86_64: WARNINGS sparse (linux-2.6.30): OK sparse (linux-2.6.31-rc5): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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] Infrared Keycode standardization
On Thu, 27 Aug 2009, Devin Heitmueller wrote: The biggest challenge with that approach is that lirc is still maintained out-of-kernel, and the inputdev solution does not require lirc at all (which is good for inexperienced end users who want their product to just work). If distros started packing lirc as a basic system daemon things would generally just work too. After all, there is plenty of other user space software one needs to do anything. The other big issue is that right now remotes get associated automaticallywith products as part of the device profile. While this has the disadvantage that there is not a uniform mechanism to specify a different remote than the one that ships with the product, it does have the advantage of the product working out-of-the-box with whatever remote it came with. It's a usability issue, but what I would consider a pretty important one. lirc isn't limited to one remote at a time. You can have many different remotes supported at once. So it's not always necessary to know which remote you have before the remote will work. -- 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] Infrared Keycode standardization
On Thu, Aug 27, 2009 at 2:29 PM, Trent Piephoxy...@speakeasy.org wrote: On Thu, 27 Aug 2009, Devin Heitmueller wrote: The biggest challenge with that approach is that lirc is still maintained out-of-kernel, and the inputdev solution does not require lirc at all (which is good for inexperienced end users who want their product to just work). If distros started packing lirc as a basic system daemon things would generally just work too. After all, there is plenty of other user space software one needs to do anything. Sure, and when that day comes my opinion will change. In the meantime, users will see a regression (their remotes will stop working whereas they worked before the upgrade). The other big issue is that right now remotes get associated automaticallywith products as part of the device profile. While this has the disadvantage that there is not a uniform mechanism to specify a different remote than the one that ships with the product, it does have the advantage of the product working out-of-the-box with whatever remote it came with. It's a usability issue, but what I would consider a pretty important one. lirc isn't limited to one remote at a time. You can have many different remotes supported at once. So it's not always necessary to know which remote you have before the remote will work. I recognize that lirc can support multiple remotes. However, at a minimum the lirc receiver should work out of the box with the remote the product comes with. And that means there needs to be some way in the driver to associate the tuner with some remote control profile that has its layout defined in lirc. Sure, if the user wants to then say I want to use this different remote instead... then that should be supported as well if the user does the appropriate configuration. While I can appreciate the desire to support all sorts of advanced configurations, this shouldn't be at the cost of the simple configurations not working out-of-the-box. 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] Infrared Keycode standardization
On Thu, Aug 27, 2009 at 04:57:10AM -0300, Mauro Carvalho Chehab wrote: After years of analyzing the existing code and receiving/merging patches related to IR, and taking a looking at the current scenario, it is clear to me that something need to be done, in order to have some standard way to map and to give precise key meanings for each used media keycode found on include/linux/input.h. Just as an example, I've parsed the bigger keymap file we have (linux/media/common/ir-common.c). Most IR's have less than 40 keys, most are common between several different models. Yet, we've got almost 500 different mappings there (and I removed from my parser all the obvious keys that there weren't any comment about what is labeled for that key on the IR). The same key name is mapped differently, depending only at the wish of the patch author, as shown at: http://linuxtv.org/wiki/index.php/Ir-common.c It doesn't come by surprise, but currently, almost all media player applications don't care to properly map all those keys. I've tried to find comments and/or descriptions about each media keys defined at input.h without success. Just a few keys are commented at the file itself. (or maybe I've just seek them at the wrong places). So, I took the initiative of doing a proposition for standardizing those keys at: http://linuxtv.org/wiki/index.php/Proposal I welcome this effort. It would be nice to have some kind of consistent behaviour between devices. But just limiting the effort to IR devices doesn't make sense. It shouldn't matter how the device is connected. FASTWORWARD,REWIND,FORWARD and BACK aren't very clear. To me it would make most sense if FASTFORWARD and REWIND were paired and FORWARD and BACK were paired. I actually have those two a bit confused in ati_remote2 too where I used FASTFORWARD and BACK. I suppose it should be REWIND instead. Also I should probably use ZOOM for the maximize/restore button (it's FRONT now), and maybe SETUP instead of ENTER for another. It has a picture of a checkbox, Windows software apparently shows a setup menu when it's pressed. There are also a couple of buttons where no keycode really seems to match. One is the mouse button drag. I suppose I could implement the drag lock feature in the driver but I'm not sure if that's a good idea. It would make that button special and unmappable. Currently I have that mapped to EDIT IIRC. The other oddball button has a picture of a stopwatch (I think, it's not very clear). Currently it uses COFFEE, but maybe TIMER or something like that should be added. The Windows software's manual just say it toggles TV-on-demand, but I have no idea what that actually is. -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ -- 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] Infrared Keycode standardization
I recognize that lirc can support multiple remotes. However, at a minimum the lirc receiver should work out of the box with the remote the product comes with. And that means there needs to be some way in the driver to associate the tuner with some remote control profile that has its layout defined in lirc. Sure, if the user wants to then say I want to use this different remote instead... then that should be supported as well if the user does the appropriate configuration. No doubt that lirc has its usage, but its usage requires either an out-of-tree kernel module, whose setup is not trivial, especially if the distro comes without support for it, or its event interface. From what I've found looking at a few lirc kernel modules, they also need a better glue with the device drivers, to do some needed locks. Either way, lirc setup is not that easy, since you need to properly configure the /etc/lirc*conf, in order to match your board, your IR and your desired applications. The event interface also requires that you need to have your device connected before calling the daemon, and that the user discover what's the event interface used by a device, to fill its command line: $ lircd -H devinput -d /dev/input/event6 IMHO, this has practical usage only with non-hotpluggable (e. g. PCI) devices. Yet, if we provide a standard set of defined keys for IR, it would be possible to have standard configurations for event interface on lirc that will work with the IR that is provided together with the device, since the keycodes for starting TV, changing channels, etc will be the same no matter what video board you're using. So, it would be easier for distros to find some ways for it to work out-of-the-box with their systems, provided that someone invest some time improving the lirc event interface to better work with hot-pluggable devices or on create some udev rules to start/stop lircd when an IR event interface is created. While I can appreciate the desire to support all sorts of advanced configurations, this shouldn't be at the cost of the simple configurations not working out-of-the-box. Agreed. The usage of lirc should be optional, not mandatory. 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] Infrared Keycode standardization
Em Thu, 27 Aug 2009 13:17:57 -0400 Devin Heitmueller dheitmuel...@kernellabs.com escreveu: On Thu, Aug 27, 2009 at 1:06 PM, Peter Brouwerpb.mailli...@googlemail.com wrote: Mauro Carvalho Chehab wrote: Hi Mauro, All Would it be an alternative to let lirc do the mapping and just let the driver pass the codes of the remote to the event port. For most devices, this is already allowed, via the standard EVIOCGKEYCODE/EVIOCSKEYCODE ioctl. There's a small application showing how to change the keycodes. It is called keytable, and it is avalable at v4l2-apps/util directory at our development tree: http://linuxtv.org/hg/v4l-dvb Yet, there are some DVB-only devices that use a different way to support event interface that doesn't allow userspace to replace the IR tables. I've looked on the dvb-usb code recently. While a patch for it is not trivial, it shouldn't be that hard to change it to support the key GET/SET ioctls, but a patch for it requires some care, since it will touch on several different places and drivers. I'll probably try to address this later. 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: HVR 1300: DVB channel lock problems since 2.6.28
ld...@hubstar.net wrote: Another suggestion, in mythtv, try increasing the signal something timeout - I think the default is 1500ms. Or scan has an option -5 (I think -- sorry its been a while and my box is recording) that increases the time wait before giving up. I stand corrected. scan seems to find all channels while mythTV doesn't find any with 2.6.31-rc7. I have tried all various (very) high time waits with no success. I think I have to head over to the mythTV list... Thanks for your help! Martin. -- 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] Infrared Keycode standardization
On Thu, Aug 27, 2009 at 09:36:36PM +0300, Ville Syrjälä wrote: On Thu, Aug 27, 2009 at 04:57:10AM -0300, Mauro Carvalho Chehab wrote: After years of analyzing the existing code and receiving/merging patches related to IR, and taking a looking at the current scenario, it is clear to me that something need to be done, in order to have some standard way to map and to give precise key meanings for each used media keycode found on include/linux/input.h. Just as an example, I've parsed the bigger keymap file we have (linux/media/common/ir-common.c). Most IR's have less than 40 keys, most are common between several different models. Yet, we've got almost 500 different mappings there (and I removed from my parser all the obvious keys that there weren't any comment about what is labeled for that key on the IR). The same key name is mapped differently, depending only at the wish of the patch author, as shown at: http://linuxtv.org/wiki/index.php/Ir-common.c It doesn't come by surprise, but currently, almost all media player applications don't care to properly map all those keys. I've tried to find comments and/or descriptions about each media keys defined at input.h without success. Just a few keys are commented at the file itself. (or maybe I've just seek them at the wrong places). So, I took the initiative of doing a proposition for standardizing those keys at: http://linuxtv.org/wiki/index.php/Proposal I welcome this effort. It would be nice to have some kind of consistent behaviour between devices. But just limiting the effort to IR devices doesn't make sense. It shouldn't matter how the device is connected. FASTWORWARD,REWIND,FORWARD and BACK aren't very clear. To me it would make most sense if FASTFORWARD and REWIND were paired and FORWARD and BACK were paired. I actually have those two a bit confused in ati_remote2 too where I used FASTFORWARD and BACK. I suppose it should be REWIND instead. Also I should probably use ZOOM for the maximize/restore button (it's FRONT now), and maybe SETUP instead of ENTER for another. It has a picture of a checkbox, Windows software apparently shows a setup menu when it's pressed. There are also a couple of buttons where no keycode really seems to match. One is the mouse button drag. I suppose I could implement the drag lock feature in the driver but I'm not sure if that's a good idea. It would make that button special and unmappable. Currently I have that mapped to EDIT IIRC. Unmappable keys should probably emit KEY_UNKNOWN. When I last talked with Richard Hughes there was an idea that userspace may detect KEY_UNKNOWN and alert user that key needs to be mapped since it lacks standard assignment. EV_MSC/MSC_SCAN was supposed to aid in fuguring out what key it was so that usersoace can issue proper EVIOCSKEYCODE... The other oddball button has a picture of a stopwatch (I think, it's not very clear). Currently it uses COFFEE, but maybe TIMER or something like that should be added. The Windows software's manual just say it toggles TV-on-demand, but I have no idea what that actually is. I'd start by looking at HID usage tables and borrowing [missing] definitions from there. Patches commenting on intended use of input keycodes are always welcome. -- Dmitry -- 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
[PULL] http://kernellabs.com/hg/~mkrufky/tda18271
Mauro, Please pull from: http://kernellabs.com/hg/~mkrufky/tda18271 for the following: - tda18271: simplify debug printk macros - tda18271: remove excess whitespace from tda_foo printk macros - tda18271: allow drivers to request RF tracking filter calibration during attach tda18271-fe.c | 20 ++-- tda18271-priv.h | 26 +- tda18271.h |3 +++ 3 files changed, 34 insertions(+), 15 deletions(-) Regards, Mike Krufky -- 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] Infrared Keycode standardization
On Thu, Aug 27, 2009 at 06:06:13PM +0100, Peter Brouwer wrote: Mauro Carvalho Chehab wrote: Hi Mauro, All Would it be an alternative to let lirc do the mapping and just let the driver pass the codes of the remote to the event port. I don't think that blindly passing IR codes through input layer is a good idea, for the same reason we don't do that for HID and PS/2 anymore - task of the kernel is to provide unified interface to the hardware devices instead of letting userspace deal with the raw data streams. -- Dmitry -- 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] Add support for RoverMedia TV Link Pro FM v2
В сообщении от Четверг 27 августа 2009 21:04:59 автор Eugene Yudin написал:
Hello.
This patch add support for RoverMedia TV Link Pro FM card based on saa7134.
...
Sorry, I forgot some things. All is working now.
This patch add support for RoverMedia TV Link Pro FM card based on saa7134.
Signed-off-by: Eugene Yudin eugene.yu...@gmail.com
Best Regards, Eugene.
diff -uprN a/linux/Documentation/video4linux/CARDLIST.saa7134
b/linux/Documentation/video4linux/CARDLIST.saa7134
--- a/linux/Documentation/video4linux/CARDLIST.saa7134 2009-08-26
12:07:09.0 +0400
+++ b/linux/Documentation/video4linux/CARDLIST.saa7134 2009-08-27
20:59:24.946147754 +0400
@@ -168,3 +168,4 @@
167 - Beholder BeholdTV 609 RDS[5ace:6092]
168 - Beholder BeholdTV 609 RDS[5ace:6093]
169 - Compro VideoMate S350/S300 [185b:c900]
+170 - RoverMedia TV Link Pro FM[19d1:0138]
diff -uprN a/linux/drivers/media/video/saa7134/saa7134-cards.c
b/linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c 2009-08-27
20:27:10.0 +0400
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c 2009-08-28
00:57:15.190205787 +0400
@@ -5182,6 +5182,56 @@ struct saa7134_board saa7134_boards[] =
.amux = LINE1
} },
},
+ [SAA7134_BOARD_ROVERMEDIA_LINK_PRO_FM] = {
+ /* Eugene Yudin eugene.yu...@gmail.com */
+ .name = RoverMedia TV Link Pro FM,
+ .audio_clock= 0x0020,
+ .tuner_type = TUNER_PHILIPS_FMD1216ME_MK3,
+ .radio_type = UNSET,
+ .tuner_addr = ADDR_UNSET,
+ .radio_addr = ADDR_UNSET,
+ .tda9887_conf = TDA9887_PRESENT,
+
+ .gpiomask = 0xe000,
+ .inputs = {{
+ .name = name_tv,
+ .vmux = 1,
+ .amux = TV,
+ .gpio = 0x8000,
+ .tv = 1,
+ },{
+ .name = name_tv_mono,
+ .vmux = 1,
+ .amux = LINE2,
+ .gpio = 0x,
+ .tv = 1,
+ },{
+ .name = name_comp1,
+ .vmux = 0,
+ .amux = LINE2,
+ .gpio = 0x4000,
+ },{
+ .name = name_comp2,
+ .vmux = 3,
+ .amux = LINE2,
+ .gpio = 0x4000,
+ },{
+ .name = name_svideo,
+ .vmux = 8,
+ .amux = LINE2,
+ .gpio = 0x4000,
+ }},
+ .radio = {
+ .name = name_radio,
+ .amux = LINE2,
+ .gpio = 0x2000,
+ },
+ .mute = {
+ .name = name_mute,
+ .amux = TV,
+ .gpio = 0x8000,
+ },
+ },
};
const unsigned int saa7134_bcount = ARRAY_SIZE(saa7134_boards);
@@ -6296,6 +6346,12 @@ struct pci_device_id saa7134_pci_tbl[] =
.subdevice= 0xc900,
.driver_data = SAA7134_BOARD_VIDEOMATE_S350,
}, {
+ .vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7134,
+ .subvendor= 0x19d1, /* RoverMedia */
+ .subdevice= 0x0138, /* LifeView FlyTV Prime30 OEM */
+ .driver_data = SAA7134_BOARD_ROVERMEDIA_LINK_PRO_FM,
+ }, {
/* --- boards without eeprom + subsystem ID --- */
.vendor = PCI_VENDOR_ID_PHILIPS,
.device = PCI_DEVICE_ID_PHILIPS_SAA7134,
@@ -6656,6 +6712,7 @@ int saa7134_board_init1(struct saa7134_d
case SAA7134_BOARD_REAL_ANGEL_220:
case SAA7134_BOARD_KWORLD_PLUS_TV_ANALOG:
case SAA7134_BOARD_AVERMEDIA_GO_007_FM_PLUS:
+ case SAA7134_BOARD_ROVERMEDIA_LINK_PRO_FM:
dev-has_remote = SAA7134_REMOTE_GPIO;
break;
case SAA7134_BOARD_FLYDVBS_LR300:
diff -uprN a/linux/drivers/media/video/saa7134/saa7134-input.c
b/linux/drivers/media/video/saa7134/saa7134-input.c
--- a/linux/drivers/media/video/saa7134/saa7134-input.c 2009-08-26
12:07:11.0 +0400
+++ b/linux/drivers/media/video/saa7134/saa7134-input.c 2009-08-27
19:49:42.0 +0400
@@ -456,6 +456,7 @@ int saa7134_input_init1(struct saa7134_d
case SAA7134_BOARD_FLYVIDEO3000:
case SAA7134_BOARD_FLYTVPLATINUM_FM:
case SAA7134_BOARD_FLYTVPLATINUM_MINI2:
+ case SAA7134_BOARD_ROVERMEDIA_LINK_PRO_FM:
ir_codes = ir_codes_flyvideo;
mask_keycode = 0xEC0;
[PATCH] Fix working LifeView FlyVideo 3000 Card
Fix this bug for this card and clones:
Hi, for a couple of days now, my lifeview PCI hybrid card that worked
flawlessly for the last 2 years doesn't work. The problem is with the driver
from what I understand from the logs.
Today 23/8/2009 I tried the drivers within vanilla kernel 2.6.30.5 (i386 and
amd64) and then separately latest mercurial snapshot. I always use latest
mercurial snapshot updating every time a new kernel is released.
This card works within Windows XP. I also switched the PCI slot but that
didn't help.
Now all is working great.
Signed-off-by: Eugene Yudin eugene.yu...@gmail.com
Best Regards, Eugene.
diff -uprN a/linux/drivers/media/video/saa7134/saa7134-cards.c
b/linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c 2009-08-27
20:27:10.0 +0400
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c 2009-08-28
01:05:14.530155113 +0400
@@ -103,6 +103,7 @@ struct saa7134_board saa7134_boards[] =
.radio_type = UNSET,
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
+ .tda9887_conf = TDA9887_PRESENT,
.gpiomask = 0xe000,
.inputs = {{
--
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] Fix working LifeView FlyVideo 3000 Card
В сообщении от Пятница 28 августа 2009 01:12:53 автор Eugene Yudin написал: Fix this bug for this card and clones: Hi, for a couple of days now, my lifeview PCI hybrid card that worked flawlessly for the last 2 years doesn't work. The problem is with the driver from what I understand from the logs. Today 23/8/2009 I tried the drivers within vanilla kernel 2.6.30.5 (i386 and amd64) and then separately latest mercurial snapshot. I always use latest mercurial snapshot updating every time a new kernel is released. This card works within Windows XP. I also switched the PCI slot but that didn't help. Now all is working great. Signed-off-by: Eugene Yudin eugene.yu...@gmail.com Best Regards, Eugene. diff -uprN a/linux/drivers/media/video/saa7134/saa7134-cards.c b/linux/drivers/media/video/saa7134/saa7134-cards.c ... Also tuner option is processed correctly. It is important not to forget to specify in the modprobe.conf: alias char-major-81 videodev alias char-major-81-0 saa7134 This is the usual line of instructions, but nevertheless not all of them should ... -- 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] Infrared Keycode standardization
On Thu, 27 Aug 2009 19:06:13 +0200, Peter Brouwer pb.mailli...@googlemail.com wrote: After years of analyzing the existing code and receiving/merging patches related to IR, and taking a looking at the current scenario, it is clear to me that something need to be done, in order to have some standard way to map and to give precise key meanings for each used media keycode found on include/linux/input.h. snip Hi all, Some end user thoughts, perhaps unwelcome but here it goes :) I think that standardization of buttons is really needed that application programmers can relly on, for example I see this like following: I think that specific MCE compatible buttons need to be implemented that are specific on most todays remotes. And I imagine a Linux Media Center that works out-of-the-box. I plug in my Linux supported card, point my remote and press Media center button which runs media center application. Because it's standard and that's applications programers implemeted it as key that triggers their app. If press Videos button on my remote, the app switches to videos directory, because it's standard, and most remotes have it, etc. http://www.spinics.net/lists/linux-media/msg07705.html And thinking of that, I have configuring nothing, it's already configured because of standardization of buttons. And, if some advanced user doesn't like this behavior, he can always tamper configuration files to suite his need. Forgive me if I'm missing something, as I don't know how it all works together, but I think you've figured out the point of the meaning :). I also welcome this effort. Cheers, Samuel -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ -- 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] Infrared Keycode standardization
Em Thu, 27 Aug 2009 21:36:36 +0300 Ville Syrjälä syrj...@sci.fi escreveu: I welcome this effort. It would be nice to have some kind of consistent behaviour between devices. But just limiting the effort to IR devices doesn't make sense. It shouldn't matter how the device is connected. Agreed. FASTWORWARD,REWIND,FORWARD and BACK aren't very clear. To me it would make most sense if FASTFORWARD and REWIND were paired and FORWARD and BACK were paired. I actually have those two a bit confused in ati_remote2 too where I used FASTFORWARD and BACK. I suppose it should be REWIND instead. Makes sense. I updated it at the wiki. I also tried to group the keycodes by function there. Also I should probably use ZOOM for the maximize/restore button (it's FRONT now), and maybe SETUP instead of ENTER for another. It has a picture of a checkbox, Windows software apparently shows a setup menu when it's pressed. There are also a couple of buttons where no keycode really seems to match. One is the mouse button drag. I suppose I could implement the drag lock feature in the driver but I'm not sure if that's a good idea. It would make that button special and unmappable. Currently I have that mapped to EDIT IIRC. I'm not sure what we should do with those buttons. Probably, the most complete IR spec is the RC5 codes: http://c6000.spectrumdigital.com/davincievm/revf/files/msp430/rc5_codes.pdf (not sure if this table is complete or accurate, but on a search I did today, this is the one that gave me a better documentation) I suspect that, after solving the most used cases, we'll need to take a better look on it, identifying the missing cases of the real implementations and add them to input.h. The other oddball button has a picture of a stopwatch (I think, it's not very clear). Currently it uses COFFEE, but maybe TIMER or something like that should be added. The Windows software's manual just say it toggles TV-on-demand, but I have no idea what that actually is. Hmm... Maybe TV-on-demand is another name for pay-per-view? 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] Infrared Keycode standardization
Em Thu, 27 Aug 2009 13:15:12 -0700 Dmitry Torokhov dmitry.torok...@gmail.com escreveu: On Thu, Aug 27, 2009 at 09:36:36PM +0300, Ville Syrjälä wrote: On Thu, Aug 27, 2009 at 04:57:10AM -0300, Mauro Carvalho Chehab wrote: After years of analyzing the existing code and receiving/merging patches related to IR, and taking a looking at the current scenario, it is clear to me that something need to be done, in order to have some standard way to map and to give precise key meanings for each used media keycode found on include/linux/input.h. Just as an example, I've parsed the bigger keymap file we have (linux/media/common/ir-common.c). Most IR's have less than 40 keys, most are common between several different models. Yet, we've got almost 500 different mappings there (and I removed from my parser all the obvious keys that there weren't any comment about what is labeled for that key on the IR). The same key name is mapped differently, depending only at the wish of the patch author, as shown at: http://linuxtv.org/wiki/index.php/Ir-common.c It doesn't come by surprise, but currently, almost all media player applications don't care to properly map all those keys. I've tried to find comments and/or descriptions about each media keys defined at input.h without success. Just a few keys are commented at the file itself. (or maybe I've just seek them at the wrong places). So, I took the initiative of doing a proposition for standardizing those keys at: http://linuxtv.org/wiki/index.php/Proposal I welcome this effort. It would be nice to have some kind of consistent behaviour between devices. But just limiting the effort to IR devices doesn't make sense. It shouldn't matter how the device is connected. FASTWORWARD,REWIND,FORWARD and BACK aren't very clear. To me it would make most sense if FASTFORWARD and REWIND were paired and FORWARD and BACK were paired. I actually have those two a bit confused in ati_remote2 too where I used FASTFORWARD and BACK. I suppose it should be REWIND instead. Also I should probably use ZOOM for the maximize/restore button (it's FRONT now), and maybe SETUP instead of ENTER for another. It has a picture of a checkbox, Windows software apparently shows a setup menu when it's pressed. There are also a couple of buttons where no keycode really seems to match. One is the mouse button drag. I suppose I could implement the drag lock feature in the driver but I'm not sure if that's a good idea. It would make that button special and unmappable. Currently I have that mapped to EDIT IIRC. Unmappable keys should probably emit KEY_UNKNOWN. When I last talked with Richard Hughes there was an idea that userspace may detect KEY_UNKNOWN and alert user that key needs to be mapped since it lacks standard assignment. EV_MSC/MSC_SCAN was supposed to aid in fuguring out what key it was so that usersoace can issue proper EVIOCSKEYCODE... This seems to be a good idea, for those keys that aren't at rc5 spec. The other oddball button has a picture of a stopwatch (I think, it's not very clear). Currently it uses COFFEE, but maybe TIMER or something like that should be added. The Windows software's manual just say it toggles TV-on-demand, but I have no idea what that actually is. I'd start by looking at HID usage tables and borrowing [missing] definitions from there. Patches commenting on intended use of input keycodes are always welcome. After we've agreed on a common base, I'll send a patch documenting the keys as used on IR. It would be good if you could take some time and see if I'm not abusing of any key at the current proposal[1]. Some of the used keys may already be mapped to do something else at kde, gnome or x11. [1] http://linuxtv.org/wiki/index.php/Proposal 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] Infrared Keycode standardization
On Thu, Aug 27, 2009 at 5:58 PM, Mauro Carvalho Chehabmche...@infradead.org wrote: Em Thu, 27 Aug 2009 21:36:36 +0300 Ville Syrjälä syrj...@sci.fi escreveu: I welcome this effort. It would be nice to have some kind of consistent behaviour between devices. But just limiting the effort to IR devices doesn't make sense. It shouldn't matter how the device is connected. Agreed. FASTWORWARD,REWIND,FORWARD and BACK aren't very clear. To me it would make most sense if FASTFORWARD and REWIND were paired and FORWARD and BACK were paired. I actually have those two a bit confused in ati_remote2 too where I used FASTFORWARD and BACK. I suppose it should be REWIND instead. Makes sense. I updated it at the wiki. I also tried to group the keycodes by function there. Also I should probably use ZOOM for the maximize/restore button (it's FRONT now), and maybe SETUP instead of ENTER for another. It has a picture of a checkbox, Windows software apparently shows a setup menu when it's pressed. There are also a couple of buttons where no keycode really seems to match. One is the mouse button drag. I suppose I could implement the drag lock feature in the driver but I'm not sure if that's a good idea. It would make that button special and unmappable. Currently I have that mapped to EDIT IIRC. I'm not sure what we should do with those buttons. Probably, the most complete IR spec is the RC5 codes: http://c6000.spectrumdigital.com/davincievm/revf/files/msp430/rc5_codes.pdf (not sure if this table is complete or accurate, but on a search I did today, this is the one that gave me a better documentation) I suspect that, after solving the most used cases, we'll need to take a better look on it, identifying the missing cases of the real implementations and add them to input.h. The other oddball button has a picture of a stopwatch (I think, it's not very clear). Currently it uses COFFEE, but maybe TIMER or something like that should be added. The Windows software's manual just say it toggles TV-on-demand, but I have no idea what that actually is. Hmm... Maybe TV-on-demand is another name for pay-per-view? 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 Since we're on the topic of IR support, there are probably a couple of other things we may want to be thinking about if we plan on refactoring the API at all: 1. The fact that for RC5 remote controls, the tables in ir-keymaps.c only have the second byte. In theory, they should have both bytes since the vendor byte helps prevents receiving spurious commands from unrelated remote controls. We should include the ability to ignore the vendor byte so we can continue to support all the remotes currently in the ir-keymaps.c where we don't know what the vendor byte should contain. 2.. The fact that the current API provides no real way to change the mode of operation for the IR receiver, for those receivers that support multiple modes (NEC/RC5/RC6). While you have the ability to change the mapping table from userland via the keytable program, there is currently no way to tell the IR receiver which mode to operate in. One would argue that the above keymaps structure should include new fields to indicate what type of remote it is (NEC/RC5/RC6 etc), as well as field to indicate that the vendor codes are absent from the key mapping for that remote). Given this, I can change the dib0700 and em28xx IR receivers to automatically set the IR capture mode appropriate based on which remote is in the device profile. 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: Hauppauge 2250 - second tuner is only half working - FIXED
Problem fixed. Both halves of tuner 2 work. The required drivers are in www.kernellabs.com/hg/~stoth/saa7164-dev. Thanks Steve Toth. -- 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] Add support for RoverMedia TV Link Pro FM v2
Hi Eugene,
Am Freitag, den 28.08.2009, 00:59 +0400 schrieb Eugene Yudin:
В сообщении от Четверг 27 августа 2009 21:04:59 автор Eugene Yudin написал:
Hello.
This patch add support for RoverMedia TV Link Pro FM card based on saa7134.
...
Sorry, I forgot some things. All is working now.
This patch add support for RoverMedia TV Link Pro FM card based on saa7134.
I bet you are still struggling with the tuner.
The FMD1216ME MK3, which has also support for digital TV, is very
unlikely to be found on such a device.
Most likely you have one of the current tuner=38 TCL MK3 clones sitting
on it.
Compared to the original tuner and the known clones, the FMD will have
missing channels and a grainy picture on very low VHF channels. Since
you don't have such an FMD, likely you can't realize that.
I suggest to start with tuner=38, enable debug=2 for tda9887 and switch
between 2 or three channels and try also the radio mode. Is a tda9887
active?
It is important to know, if this could be really some ME (MultiEurope).
Only then I would see an good argument to eventually duplicate all the
code for a new card entry. The other tuner mess is since ever and
RoverMedia seems to produce a lot of clones, like so many others since
2002. Else only auto detect it and use FV3K entry for it.
Is four in one checked on the tuner's sticker?
Cheers,
Hermann
Signed-off-by: Eugene Yudin eugene.yu...@gmail.com
Best Regards, Eugene.
diff -uprN a/linux/Documentation/video4linux/CARDLIST.saa7134
b/linux/Documentation/video4linux/CARDLIST.saa7134
--- a/linux/Documentation/video4linux/CARDLIST.saa71342009-08-26
12:07:09.0 +0400
+++ b/linux/Documentation/video4linux/CARDLIST.saa71342009-08-27
20:59:24.946147754 +0400
@@ -168,3 +168,4 @@
167 - Beholder BeholdTV 609 RDS[5ace:6092]
168 - Beholder BeholdTV 609 RDS[5ace:6093]
169 - Compro VideoMate S350/S300 [185b:c900]
+170 - RoverMedia TV Link Pro FM[19d1:0138]
diff -uprN a/linux/drivers/media/video/saa7134/saa7134-cards.c
b/linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c 2009-08-27
20:27:10.0 +0400
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c 2009-08-28
00:57:15.190205787 +0400
@@ -5182,6 +5182,56 @@ struct saa7134_board saa7134_boards[] =
.amux = LINE1
} },
},
+ [SAA7134_BOARD_ROVERMEDIA_LINK_PRO_FM] = {
+ /* Eugene Yudin eugene.yu...@gmail.com */
+ .name = RoverMedia TV Link Pro FM,
+ .audio_clock= 0x0020,
+ .tuner_type = TUNER_PHILIPS_FMD1216ME_MK3,
+ .radio_type = UNSET,
+ .tuner_addr = ADDR_UNSET,
+ .radio_addr = ADDR_UNSET,
+ .tda9887_conf = TDA9887_PRESENT,
+
+ .gpiomask = 0xe000,
+ .inputs = {{
+ .name = name_tv,
+ .vmux = 1,
+ .amux = TV,
+ .gpio = 0x8000,
+ .tv = 1,
+ },{
+ .name = name_tv_mono,
+ .vmux = 1,
+ .amux = LINE2,
+ .gpio = 0x,
+ .tv = 1,
+ },{
+ .name = name_comp1,
+ .vmux = 0,
+ .amux = LINE2,
+ .gpio = 0x4000,
+ },{
+ .name = name_comp2,
+ .vmux = 3,
+ .amux = LINE2,
+ .gpio = 0x4000,
+ },{
+ .name = name_svideo,
+ .vmux = 8,
+ .amux = LINE2,
+ .gpio = 0x4000,
+ }},
+ .radio = {
+ .name = name_radio,
+ .amux = LINE2,
+ .gpio = 0x2000,
+ },
+ .mute = {
+ .name = name_mute,
+ .amux = TV,
+ .gpio = 0x8000,
+ },
+ },
};
const unsigned int saa7134_bcount = ARRAY_SIZE(saa7134_boards);
@@ -6296,6 +6346,12 @@ struct pci_device_id saa7134_pci_tbl[] =
.subdevice= 0xc900,
.driver_data = SAA7134_BOARD_VIDEOMATE_S350,
}, {
+ .vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7134,
+ .subvendor= 0x19d1, /* RoverMedia */
+ .subdevice= 0x0138, /* LifeView FlyTV Prime30 OEM */
+ .driver_data = SAA7134_BOARD_ROVERMEDIA_LINK_PRO_FM,
+ }, {
/* --- boards without eeprom + subsystem ID --- */
.vendor = PCI_VENDOR_ID_PHILIPS,
.device
Re: [PATCH] Fix working LifeView FlyVideo 3000 Card
Eugene,
Am Freitag, den 28.08.2009, 01:12 +0400 schrieb Eugene Yudin:
Fix this bug for this card and clones:
Hi, for a couple of days now, my lifeview PCI hybrid card that worked
flawlessly for the last 2 years doesn't work. The problem is with the driver
from what I understand from the logs.
Today 23/8/2009 I tried the drivers within vanilla kernel 2.6.30.5 (i386
and
amd64) and then separately latest mercurial snapshot. I always use latest
mercurial snapshot updating every time a new kernel is released.
This card works within Windows XP. I also switched the PCI slot but that
didn't help.
Now all is working great.
Signed-off-by: Eugene Yudin eugene.yu...@gmail.com
Best Regards, Eugene.
diff -uprN a/linux/drivers/media/video/saa7134/saa7134-cards.c
b/linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c 2009-08-27
20:27:10.0 +0400
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c 2009-08-28
01:05:14.530155113 +0400
@@ -103,6 +103,7 @@ struct saa7134_board saa7134_boards[] =
.radio_type = UNSET,
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
+ .tda9887_conf = TDA9887_PRESENT,
I can assure, that there is no tda9887 on all the earlier FV3K boards
and I still have one and it was investigated very carefully.
See my previous post for an eventually possible alternative solution.
Cheers,
Hermann
.gpiomask = 0xe000,
.inputs = {{
--
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] Add support for RoverMedia TV Link Pro FM v2
... Compared to the original tuner and the known clones, the FMD will have missing channels and a grainy picture on very low VHF channels. Since you don't have such an FMD, likely you can't realize that. For the record. Sorry, was of cause meant the other way round. You will see this on tuner=38 like types and not on the FMD. The genuine FMD can also be identified by its radio and tda9887 initialization behavior. Hermann -- 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: Pinnacle PCTV 310i active antenna
Hi Martin, Am Dienstag, den 28.07.2009, 06:15 +0200 schrieb hermann pitton: Hi Martin, Am Montag, den 27.07.2009, 21:36 +0200 schrieb Martin Konopka: Hi Hermann, I'm using kernel 2.6.28-11 on a mythbuntu distribution. I tried to load the drivers with the card=50 option and antenna_pwr=1. [ 8745.007384] saa7133[0]: subsystem: 11bd:002f, board: Pinnacle PCTV 300i DVB-T + PAL [card=50,insmod option] [ 8745.007628] saa7133[0]: board init: gpio is 600c000 [ 8745.007641] saa7133[0]: gpio: mode=0x0008000 in=0x6004000 out=0x0008000 [pre-init] [ 8745.148374] tuner' 1-004b: chip found @ 0x96 (saa7133[0]) [..] [ 8802.196576] dvb_init() allocating 1 frontend [ 8802.196583] saa7133[0]/dvb: pinnacle 300i dvb setup [ 8802.196845] mt352_read_register: readreg error (reg=127, ret==-5) [ 8802.196953] saa7133[0]/dvb: frontend initialization failed The antenna power is not activated. I then installed microsoft stuff. To my horror it turned out that the active antenna switch is greyed out in Pinnacle's TV application. So the card obviously does not have an active antenna, although the manual mentions it. Probably copy and paste from the 300i manual. Regards, Martin thanks a lot for reporting and for going to all that testing stuff. Since neither Hartmut nor me ever had such a card, Hartmut would be much better than me on such, we should be able to exclude active voltage to support the antenna on it now. For the other issues since 2.6.26 I don't have new ideas and such cards seem not to be available on some e/xbay currently. The Hauppauge/Pinnacle US guys can't help much either currently and there is no reason to blame them for something they don't know. (yet) So it is only what is posted so far. Thanks, Hermann also for the record. The early variant of the 310i I have now has clearly support for 5 Volt antenna output. Easy to measure. I can install currently three different driver versions under vista, all with different gpio configuration. The one for testing the 5 Volt switch for now is with the original driver CD from 2005. Unfortunately, it has also these always changing gpios, like the TS interface is always on, but the voltage switch is no problem on vista with that old XP driver. Other stuff is ... dmesg from mine. saa7133[1]: registered device video1 [v4l2] saa7133[1]: registered device vbi1 saa7133[2]: setting pci latency timer to 64 saa7133[2]: found at :04:03.0, rev: 208, irq: 21, latency: 64, mmio: 0xfebfe800 saa7133[2]: subsystem: 11bd:002f, board: Pinnacle PCTV 310i [card=101,insmod option] saa7133[2]: board init: gpio is 600e000 IRQ 21/saa7133[2]: IRQF_DISABLED is not guaranteed on shared IRQs saa7133[2]: i2c eeprom 00: bd 11 2f 00 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7133[2]: i2c eeprom 10: ff e0 60 06 ff 20 ff ff 00 30 8d 2c b0 22 ff ff saa7133[2]: i2c eeprom 20: 01 2c 01 02 02 01 04 30 98 ff 00 a5 ff 21 00 c2 saa7133[2]: i2c eeprom 30: 96 10 03 32 15 20 ff ff 0c 22 17 88 03 44 31 f9 saa7133[2]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff input: i2c IR (Pinnacle PCTV) as /class/input/input6 ir-kbd-i2c: i2c IR (Pinnacle PCTV) detected at i2c-3/3-0047/ir0 [saa7133[2]] tuner 3-004b: chip found @ 0x96 (saa7133[2]) tda829x 3-004b: setting tuner address to 61 tda829x 3-004b: type set to tda8290+75a saa7133[2]: registered device video2 [v4l2] saa7133[2]: registered device vbi2 saa7133[2]: registered device radio0 dvb_init() allocating 1 frontend DVB: registering new adapter (saa7133[0]) DVB: registering adapter 0 frontend 0 (Philips TDA10086 DVB-S)... dvb_init() allocating 1 frontend DVB: registering new adapter (saa7133[1]) DVB: registering adapter 1 frontend 0 (Philips TDA10086 DVB-S)... dvb_init() allocating 1 frontend DVB: registering new adapter (saa7133[2]) DVB: registering adapter 2 frontend 0 (Philips TDA10046H DVB-T)... tda1004x: setting up plls for 48MHz sampling clock tda1004x: found firmware revision 29 -- ok board init: gpio is 600e000 can also change to 0x600c000. BTW, not totally unrelated, the recent NXP Creatix driver for the Medion Quad (CTX944) does
Support for Terratec H7 DVB-C with CI
Hi, is any development for this card started? I would love to use this card with my debian linux MythTV htpc. I would love to provide some useful data, if someone needs it. Here are some general informations: lsusb -vvv -d 0ccd:10a3 http://pastebin.ca/1545400 Regards Sascha Zielinski -- 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] Infrared Keycode standardization
Em Thu, 27 Aug 2009 18:06:51 -0400 Devin Heitmueller dheitmuel...@kernellabs.com escreveu: Since we're on the topic of IR support, there are probably a couple of other things we may want to be thinking about if we plan on refactoring the API at all: 1. The fact that for RC5 remote controls, the tables in ir-keymaps.c only have the second byte. In theory, they should have both bytes since the vendor byte helps prevents receiving spurious commands from unrelated remote controls. We should include the ability to ignore the vendor byte so we can continue to support all the remotes currently in the ir-keymaps.c where we don't know what the vendor byte should contain. This were done due to at least two reasons: 1) Several boards uses a few GPIO bits (in general 7 or less bits) for IR. There's one logic at ir-common.ko to convert a 32 bits GPIO read into a 7 bits scancode. 2) In order to properly support the default EVIOCGKEYCODE/EVIOCSKEYCODE handlers, we need to have keycode table, where the scan code is the index. So, if we use 14 bits for it, this means that this table would reserve 16384 bytes, and will probably a very few of those bytes (on a IR with 64 keys, it would need only 64 entries). As it seems that there are some ways to replace the default getkeycode/setkeycode handlers, I suspect that we can get rid of this limitation. I'll do some tests here with a dib0700 and an em28xx devices. 2.. The fact that the current API provides no real way to change the mode of operation for the IR receiver, for those receivers that support multiple modes (NEC/RC5/RC6). While you have the ability to change the mapping table from userland via the keytable program, there is currently no way to tell the IR receiver which mode to operate in. In this case, we'll need to have a set of new ioctls at the event interface, to allow enum/get/set the IR protocol type(s) per event device. One would argue that the above keymaps structure should include new fields to indicate what type of remote it is (NEC/RC5/RC6 etc), as well as field to indicate that the vendor codes are absent from the key mapping for that remote). Given this, I can change the dib0700 and em28xx IR receivers to automatically set the IR capture mode appropriate based on which remote is in the device profile. Let's go step by step. Adding the ability of dynamically change the type of remote will likely cause major changes at the GPIO polling code, since we'll need to move some code from bttv and saa7134 into ir-functions.c and rework on it. We'll probably end by converting the remaining polling code to use high precision timers as we've done with cx88. So, we need a sort of TODO list for IR changes. A start point (on a random order) would be something like: 1) Standardize the keycodes; 2) Implement a v4l handler for EVIOCGKEYCODE/EVIOCSKEYCODE; 3) use a different arrangement for IR tables to not spend 16 K for IR table, yet allowing RC5 full table; 4) Use the common IR framework at the dvb drivers with their own iplementation; 5) Allow getkeycode/setkeycode to work with the dvb framework using the new methods; 6) implement new event ioctls (EVIOEPROTO/EVIOGPROTO/EVIOSPROTO ?), to allow enumerating/getting/setting the IR protocol types; 7) Change the non-gpio drivers to support IR protocol type; 8) Create a gpio handler that supports changing the protocol type; 9) Migrate the remaining drivers to the new gpio handler methods; 10) Merge pertinent lirc drivers; 11) Add missing keys at input.h. 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] Infrared Keycode standardization
On Thursday 27 August 2009 18:06:51 Devin Heitmueller wrote: On Thu, Aug 27, 2009 at 5:58 PM, Mauro Carvalho Chehabmche...@infradead.org wrote: Em Thu, 27 Aug 2009 21:36:36 +0300 Ville Syrjälä syrj...@sci.fi escreveu: I welcome this effort. It would be nice to have some kind of consistent behaviour between devices. But just limiting the effort to IR devices doesn't make sense. It shouldn't matter how the device is connected. Agreed. FASTWORWARD,REWIND,FORWARD and BACK aren't very clear. To me it would make most sense if FASTFORWARD and REWIND were paired and FORWARD and BACK were paired. I actually have those two a bit confused in ati_remote2 too where I used FASTFORWARD and BACK. I suppose it should be REWIND instead. Makes sense. I updated it at the wiki. I also tried to group the keycodes by function there. Also I should probably use ZOOM for the maximize/restore button (it's FRONT now), and maybe SETUP instead of ENTER for another. It has a picture of a checkbox, Windows software apparently shows a setup menu when it's pressed. There are also a couple of buttons where no keycode really seems to match. One is the mouse button drag. I suppose I could implement the drag lock feature in the driver but I'm not sure if that's a good idea. It would make that button special and unmappable. Currently I have that mapped to EDIT IIRC. I'm not sure what we should do with those buttons. Probably, the most complete IR spec is the RC5 codes: http://c6000.spectrumdigital.com/davincievm/revf/files/msp430/rc5_codes.pdf (not sure if this table is complete or accurate, but on a search I did today, this is the one that gave me a better documentation) I suspect that, after solving the most used cases, we'll need to take a better look on it, identifying the missing cases of the real implementations and add them to input.h. The other oddball button has a picture of a stopwatch (I think, it's not very clear). Currently it uses COFFEE, but maybe TIMER or something like that should be added. The Windows software's manual just say it toggles TV-on-demand, but I have no idea what that actually is. Hmm... Maybe TV-on-demand is another name for pay-per-view? 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 Since we're on the topic of IR support, there are probably a couple of other things we may want to be thinking about if we plan on refactoring the API at all: 1. The fact that for RC5 remote controls, the tables in ir-keymaps.c only have the second byte. In theory, they should have both bytes since the vendor byte helps prevents receiving spurious commands from unrelated remote controls. We should include the ability to ignore the vendor byte so we can continue to support all the remotes currently in the ir-keymaps.c where we don't know what the vendor byte should contain. 2.. The fact that the current API provides no real way to change the mode of operation for the IR receiver, for those receivers that support multiple modes (NEC/RC5/RC6). While you have the ability to change the mapping table from userland via the keytable program, there is currently no way to tell the IR receiver which mode to operate in. One would argue that the above keymaps structure should include new fields to indicate what type of remote it is (NEC/RC5/RC6 etc), as well as field to indicate that the vendor codes are absent from the key mapping for that remote). Given this, I can change the dib0700 and em28xx IR receivers to automatically set the IR capture mode appropriate based on which remote is in the device profile. Jon Smirl actually wrote some fully functional proof-of-concept IR handling code about a year ago, that included auto-detection and auto decoding of several protocols. Perhaps some of that is relevant and reusable here? (I still have a copy of the tree here somewhere...) I've been toying with the notion of extending the input device support that was added to the lirc_imon driver a bit ago, and add a full key map that delivers events (we already do this for mouse functionality), but include the ability to also use the remote and/or receiver in a raw IR mode with lircd. Wouldn't be terribly difficult I think to do something similar for the standard MCE remotes and receivers... Just a simple matter of some time and some code. Unfortunately, I'm a bit short on the time part right now... -- Jarod Wilson ja...@wilsonet.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
