Re: What ever happened to standardizing signal level?
On Sat, May 29, 2010 at 10:52 PM, hermann pitton hermann-pit...@arcor.de wrote: ...troll spam removed... Hermann, you're a known troll with clearly nothing to contribute to this thread therefore you're comments are unwelcome. Your mostly incoherent rant sounds like the ramblings of somebody who has consumed too much alcohol, and you're obviously using this mailing list as a cry for attention. I'll ask you kindly to stop wasting everyones time with your moronic nonsense and direct your harassment elsewhere. I'm sure you can find something better to do with your time then polluting this mailing list and making yourself look foolish. To everyone else, please disregard this post and the imbecile in which I'm replying to. -- 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: What ever happened to standardizing signal level?
On Sat, May 29, 2010 at 2:09 AM, Mike Booth mike_boot...@iprimus.com.au wrote: i think someone is too concerned about being precisely accurate. So much so that no-one can see the woods for the trees any more. Its not important to me that accuracy is spot on. I only want to know that when tuning the dish I'm getting \better or worse. I tend to agree with this. Ultimately what's important is not necessarily that the readings are 100% accurate, but rather simply put into some kind of universal scale that provides useful output to the user. Many users were happy to see some activity addressing this issue and unfortunately it seems to have stalled out but I'm not sure why. I honestly felt there was enough common ground being discussed that we'd have a solution by now. Regards. -- 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: What ever happened to standardizing signal level?
On Sunday 30 May 2010 09:07:46 VDR User wrote: On Sat, May 29, 2010 at 2:09 AM, Mike Booth mike_boot...@iprimus.com.au wrote: i think someone is too concerned about being precisely accurate. So much so that no-one can see the woods for the trees any more. Its not important to me that accuracy is spot on. I only want to know that when tuning the dish I'm getting \better or worse. I tend to agree with this. Ultimately what's important is not necessarily that the readings are 100% accurate, but rather simply put into some kind of universal scale that provides useful output to the user. Many users were happy to see some activity addressing this issue and unfortunately it seems to have stalled out but I'm not sure why. I honestly felt there was enough common ground being discussed that we'd have a solution by now. To the best of my knowledge Mike Krufky intended to work on this but he clearly no longer has time to do that work. Mike, can you perhaps explain what you wanted to do? Hopefully someone else can find the time to implement it. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- 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: What ever happened to standardizing signal level?
Hi, A little bit more ontopic, did anyone get around to read the signallevel of the tda18721? I wonder the register does not return any signallevel as indicated in the specifications. Markus -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tentative agenda for Helsinki mini-summit
On Sunday 23 May 2010 20:02:59 Guennadi Liakhovetski wrote: On Sun, 23 May 2010, Hans Verkuil wrote: Hi all, This is a tentative agenda for the Helsinki mini-summit on June 14-16. Please reply to this thread if you have comments or want to add topics. [snip] 8) soc-camera status. Particularly with regards to the remaining soc-camera dependencies in sensor drivers. Guennadi Liakhovetski. Don't think a formal presentation is needed, but I can tell a couple of words to clarify the current status a bit. Comments? Topics I missed? No idea whether this is a worthy and suitable topic for this meeting, but: V4L(2) video output vs. framebuffer. Problem: Currently the standard way to provide graphical output on various (embedded) displays like LCDs is to use a framebuffer driver. The interface is well supported and widely adopted in the user-space, many applications, including the X-server, various libraries like directfb, gstreamer, mplayer, etc. In the kernel space, however, the subsystem has a number of problems. It is unmaintained. The infrastructure is not being further developed, every specific hardware driver is being supported by the respective architecture community. But as video output hardware evolves, more complex displays and buses appear and have to be supported, the subsystem shows its aging. For example, there is currently no way to write reusable across multiple platforms display drivers. OTOH V4L2 has a standard vodeo output driver support, it is not very widely used, in the userspace I know only of gstreamer, that somehow supports video-output v4l2 devices in latest versions. But, being a part of the v4l2 subsystem, these drivers already now can take a full advantage of all v4l2 APIs, including the v4l2-subdev API for the driver reuse. So, how can we help graphics driver developers on the one hand by providing them with a capable driver framework (v4l2) and on the other hand by simplifying the task of interfacing to the user-space? How about a v4l2-output - fbdev translation layer? You write a v4l2-output driver and get a framebuffer device free of charge... TBH, I haven't given this too much of a thought, but so far I don't see anything that would make this impossible in principle. The video buffer management is quite different between the two systems, but maybe we can teach video-output drivers to work with just one buffer too? Anyway, feel free to tell me why this is an absolutely impossible / impractical idea;) I've added this to the agenda. I think this probably doesn't need a presentation but will be more an open discussion. I also think this is a very interesting topic to discuss more in-depth on Tuesday. Sakari, does Nokia have any framebuffer experts that might be interested in discussing this as well on Tuesday? Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- 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: Tentative agenda for Helsinki mini-summit
On Sunday 30 May 2010 09:59:59 Hans Verkuil wrote: On Wednesday 26 May 2010 17:46:16 Pawel Osciak wrote: Hi Hans, thank you for your work on this! Hans Verkuil wrote: 3) videobuf/videobuf2: what are the shortcomings, what are the requirements for a 'proper' videobuf implementation, can the existing videobuf be fixed or do we need a videobuf2. If the latter, what would be needed to convert existing drivers over to a videobuf2. Laurent Pinchart and Pawel Osciak. This I'm sure requires a presentation. As Laurent volunteered to prepare the videobuf problems presentation, I will hopefully make it before the summit with an initial (general) design for the new videobuf2 - requirements, API, things like that. So I'm thinking about a short presentation on this. What do you think? That's OK. 4) Multi-planar support. Pawel Osciak. Yes. Will provide a short status update. Is a presentation of the whole concept required? If so, I can conduct one as well. I don't think a presentation is required. 9) Driver compliance. We need a framework for V4L2 driver compliance. Hans Verkuil. I am very interested in this! 10) Discuss list of 'reference' programs to test against. Mauro? Ditto. During the memory handling brainstorming session earlier this year we also touched on creating some sort of a generic buffer model allowing for easy exchange between v4l buffers, framebuffers, texture buffers, etc. It is my opinion that we should not discuss this in Helsinki. The list of topics is already quite long and I think it is too early to start working on that. We probably need another brainstorming session first in order to come up with a reasonable proposal. I agree. Comments? Topics I missed? It would be great to touch on the following subjects if we find some time (and if people would be interested, I had little feedback on the list): 1) Custom/pluggable allocators As most of us are aware there are important problems with memory allocation in videobuf that most of us have already faced. For those unfamiliar with the topic, please see my recent RFC: http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/19581 I'd like to provide a design of an API: * for videobuf that would allow drivers to plug-in their own memory allocation routines, * future-proof enough to be usable with videobuf2 as well. Hoping for a (short-ish) discussion on that. 2) Out-of-order buffer dequeuing and per-buffer wait queues in videobuf. See: RFC: http://www.mail-archive.com/linux-media@vger.kernel.org/msg17319.html Patches: http://www.mail-archive.com/linux-media@vger.kernel.org/msg17886.html These topics should all be folded into the videobuf topic. Due to the importance of videobuf I expect that a considerable amount of time will be spend on this. On the first day I will probably put this topic last on the list and try to get through the other topics fairly quickly so that we hopefully have 2-3 hours for this topic. What makes this a difficult topic is that you have this list of relatively small sub-topics (like allocators, out-of-order dequeuing, videobuf improvements, caching, etc. etc.), but it is not always easy to see the big picture: i.e. what is the goal that you are working towards and what is the purpose for these smaller sub-topics in the bigger picture. I know that was difficult for me in the beginning, so I think it will probably help people if you also provide the big picture and the context within which to place these sub-topics. The 'big picture' also includes the memory pool idea. Not that we will discuss this in Helsinki, but people should be aware that it will be part of a next phase. BTW, the videobuf presentation(s) can be longer than 10 minutes if needed. This is the 'big topic' of the summit, so we will have more time for this. I just realized this is the second time I replied to your post :-) Still, my comments at the end of my second reply are hopefully still useful. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- 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
Version 2: Tentative agenda for Helsinki mini-summit
Hi all, This is the second version of a tentative agenda for the Helsinki mini-summit on June 14-16. Please reply to this thread if you have comments or want to add topics. If you want to attend the summit then contact Sakari Ailus (sakari.ai...@maxwell.research.nokia.com). We are very full already (over 20 attendees), so I'm not sure if there is still room left. The overall layout of the summit is to use the first day to go through all topics and either come to a conclusion quickly for the 'simple' topics, or discuss enough so that everyone understands the problem for the more complex issues. The second day will be used for in-depth discussions on those complex topics and on the third day we will go through all topics again and translate the discussions into something concrete like a time-line, action items, etc. We have a lot to discuss, so we almost certainly have to split the second day into two tracks, each discussing different topics. If we do split up, then one track will touch on the videobuf-related topics and the other on the remaining topics. The first day will also feature a few short presentations on various topics. Presentations shouldn't be longer than, say, 10 minutes tops. Please keep them as short and to the point as possible. These presentations are meant to get everyone up to speed quickly. Most of us have an extensive background in video hardware and the v4l subsystem, so you don't need to spend time explaining things. After each topic I've put the names of the main developers active in that area. If you see your name, then make sure you know the status of that topic so you can explain it to everyone else. If I think it warrants a presentation, then I will mention that. Of course, if you disagree, or want/don't want to do a presentation then just say so. It's a tentative agenda only. The topics below are in no particular order except for the first one. I am very pleased that Qualcomm has joined this project so I think it would be nice to start the meeting off with a presentation on their HW architecture. 1) Presentation on the Qualcomm video hw architecture. Most of us have no experience with Qualcomm hardware, so I've asked Jeff Zhong to give a short overview of their video hardware. 2) Removal of V4L1: status of driver conversion in the kernel, status of moving v4l1-v4l2 conversion into libv4l1. What needs to be done, when will it be done and who will do it. Driver conversion: Hans Verkuil, libv4l1 conversion: Hans de Goede. 3) videobuf/videobuf2: what are the shortcomings, what are the requirements for a 'proper' videobuf implementation, can the existing videobuf be fixed or do we need a videobuf2. If the latter, what would be needed to convert existing drivers over to a videobuf2. Related topics (custom/pluggable allocators, out-of-order buffer dequeuing and per-buffer wait queues) will also be part of this topic. Laurent Pinchart and Pawel Osciak with presentations. 4) Multi-planar support. Pawel Osciak. 5) Media Controller Roadmap. Laurent Pinchart has a presentation. 6) TO DO list regarding V4L2 core framework including the new control framework. Hans Verkuil. Will be a presentation. 7) Status of the Texas Instruments drivers: omapX (Laurent Pinchart/Hiremath Vaibhav) and DM (Sergio Aguirre). Probably should be a short presentation. 8) soc-camera status. Particularly with regards to the remaining soc-camera dependencies in sensor drivers. Guennadi Liakhovetski. 9) Driver compliance. We need a framework for V4L2 driver compliance. Hans Verkuil. 10) Discuss list of 'reference' programs to test against. Mauro Carvalho Chehab. 11) Adopting old V4L1 programs and converting to V4L2. Hans de Goede? 12) Status of intel drivers. Xiaolin Zhang. 13) Remote Controllers. Presentation by Mauro Carvalho Chehab. 14) V4L2 video output vs. framebuffer. Guennadi Liakhovetski. 15) A processing plugin API for libv4l. Hans de Goede. See: http://www.mail-archive.com/linux-media@vger.kernel.org/msg18993.html It is my understanding that we will also have X11 and gstreamer experts on hand. Topics relating to that are welcome. During the memory handling brainstorming session earlier this year we also touched on creating some sort of a generic buffer model allowing for easy exchange between v4l buffers, framebuffers, texture buffers, etc. It is my opinion that we should not discuss this in Helsinki. The list of topics is already quite long and I think it is too early to start working on that. We probably need another brainstorming session first in order to come up with a reasonable proposal. Comments? Topics I missed? Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- 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: TBS 6980 Dual Tuner PCI-e card.....not in Wiki at all?
hello, i can't comment on your questions about the Wiki, but i made the driver for TBS 6980 and i can ensure you that the driver will be released as open-source under GPL as soon as i have permission to do that, but compared to other cards at least even at the moment you can Does this card need some firmware (and if it needs is it open or closed source) -- 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 v3 0/4] WL1273 FM Radio Driver
On Monday 24 May 2010 14:21:39 Matti J. Aaltonen wrote: Hello again. And thanks for the comments. It the first patch I'm kind of suggesting a couple of additions to the general interface: signal level stuff in the hw seek struct and then a function / IOCTL for asking for minimum and maximum for the level. There are many changes I'll follow by commenting to Hans's comments: 1. WL1273_CID_FM_REGION for setting the region. This may not be a good candidate for standardization as the region control shouldn't exist in the kernel in general... Is this region relevant for receive, transmit or both? Region is relevant for receiving only. Now I've changes the naming to band because TI uses that in their latest document version. Based on this article: http://en.wikipedia.org/wiki/FM_broadcasting, there seem to be only three bands for FM radio in practice: 87.5-108, 76-90 (Japan) and 65-74 (former Soviet republics, some former eastern bloc countries). So this should be a standard control. Since the latter band is being phased out I think a menu control with just the two other bands is sufficient. And I also think this should be a control of a new FM_RX class. I know, that's not what I said last time. So sue me :-) BTW: don't forget to update the V4L2 spec when adding new controls! 2. WL1273_CID_FM_SEEK_SPACING: defines what resolution is used when scanning automatically for stations (50KHz, 100KHz or 200KHz). This could be useful in general. Could this be a field in the v4l2_hw_freq_seek struct? I think this belongs in v4l2_hw_freq_seek. I've added spacing to the hw seek struct. 3. WL1273_CID_FM_RDS_CTRL for turning on and off the RDS reception / transmission. To me this seems like a useful standard control... This already exists. You can enable/disable RDS by setting the V4L2_TUNER_SUB_RDS subchannel bit when calling S_TUNER or S_MODULATOR. I did this. 4. WL1273_CID_SEARCH_LVL for setting the threshold level when detecting radio channels when doing automatic scan. This could be useful for fine tuning because automatic scanning seems to be kind of problematic... This could also be a field in the v4l2_hw_freq_seek struct? This too seems reasonable to add to v4l2_hw_freq_seek. Although what sort of unit this level would have might be tricky. What is the unit for your hardware? I've added this as well. The unit is some kind of dB value: 8 bit signed number in 2أ�s complement format Each LSB = 1.5051 dBuV. I also added min and max values for the level. I'm uncertain about this. I wonder if this shouldn't be something that is hardcoded in the driver. Setting these levels to sensible values is not a trivial exercise. It is also very much device specific. I think it is best to do hardcode it now and once we can expose controls that are sub-device specific (this is being worked on), then we can add WL1273-specific controls for this. Could the VIDIOC_S_MODULATOR and VIDIOC_S_TUNER IOCTLs be used for setting the TX/RX mode? Not entirely sure what you want to achieve here. I gather that the radio is either receiving, transmitting or off? So it can't receive and transmit at the same time, right? Yes the radio can only transmit or receive at a time. And the states are: On (RX or TX), Off and Suspended. In the suspended mode that firmware patch is kept in the memory and it doesn't need to get uploaded again when operation resumes. would expect in that case that calling S_TUNER or S_MODULATOR would switch it to either receive or transmit mode. S_HW_FREQ_SEEK would of course also switch it to receive mode. I added this... There isn't anything to turn off the radio at the moment. Perhaps you can just automatically turn it off if nobody has the radio device or alsa device open? Yes that can be done. Also volume control could be used. But also there's nothing to put the radio to stand-by (suspension). Is there a difference in power consumption between the 'off' and 'suspend' state of the device? I assume that 'off' has the lowest power consumption. In that case I would have the driver go to suspend when no one has opened the radioX device. And if the driver is asked to go to suspend (that's the linux suspend state), then the driver can turn off the radio and on resume it will reload the firmware. Does that sound reasonable? Now there already exits a class for fm transmitters: V4L2_CTRL_CLASS_FM_TX. Should a corresponding class be created for FM tuners? I'm not sure that we need any. I think the only control that we need is to set the region, and I think that is more appropriate as a private (?) user control since it is definitely something that users should be easily able to change. OK, that's fine by me This probably should be discussed a bit more. Ok. There's also two new things. The chip supports in addition to the normal HW seek a HW block seek, which
Re: [PATCH v3 1/4] V4L2: Add features to the interface.
On Monday 24 May 2010 14:21:40 Matti J. Aaltonen wrote:
Add fields spacing, level_min, level_max and level to struct
v4l2_hw_freq_seek.
The level is used for determining which channels are considered receivable
during HW scan.
As mentioned I don't think the level stuff should be added at the moment.
The spacing field is no problem, but don't forget to update the V4L2 spec as
well. Also document there what should happen if spacing == 0 (which is the
case for existing apps). It basically boils down to the fact that the driver
uses the spacing as a hint only and will adjust it to whatever the hardware
supports.
Add VIDIOC_G_HW_FREQ_SEEK to IOCTL codes. This is used for getting the
minimum and
maximum values for the level field in the v4l2_hw_freq_seek struct.
Without level support we can drop this for now.
Regards,
Hans
Signed-off-by: Matti J. Aaltonen matti.j.aalto...@nokia.com
---
include/linux/videodev2.h |6 +-
include/media/v4l2-ioctl.h |2 ++
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 418dacf..7a81a9c 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1377,7 +1377,11 @@ struct v4l2_hw_freq_seek {
enum v4l2_tuner_type type;
__u32 seek_upward;
__u32 wrap_around;
- __u32 reserved[8];
+ __u32 spacing;
+ __s32 level_min;
+ __s32 level_max;
+ __s32 level;
+ __u32 reserved[4];
};
/*
diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
index e8ba0f2..828cf13 100644
--- a/include/media/v4l2-ioctl.h
+++ b/include/media/v4l2-ioctl.h
@@ -220,6 +220,8 @@ struct v4l2_ioctl_ops {
/* Log status ioctl */
int (*vidioc_log_status) (struct file *file, void *fh);
+ int (*vidioc_g_hw_freq_seek) (struct file *file, void *fh,
+ struct v4l2_hw_freq_seek *a);
int (*vidioc_s_hw_freq_seek) (struct file *file, void *fh,
struct v4l2_hw_freq_seek *a);
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
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 v3 4/4] V4L2: WL1273 FM Radio: Controls for the FM radio.
On Monday 24 May 2010 14:21:43 Matti J. Aaltonen wrote:
This file implements V4L2 controls for using the Texas Instruments
WL1273 FM Radio.
Signed-off-by: Matti J. Aaltonen matti.j.aalto...@nokia.com
---
drivers/media/radio/Kconfig| 15 +
drivers/media/radio/Makefile |1 +
drivers/media/radio/radio-wl1273.c | 1876
3 files changed, 1892 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/radio/radio-wl1273.c
diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index 83567b8..209fd37 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -452,4 +452,19 @@ config RADIO_TIMBERDALE
found behind the Timberdale FPGA on the Russellville board.
Enabling this driver will automatically select the DSP and tuner.
+config RADIO_WL1273
+ tristate Texas Instruments WL1273 I2C FM Radio
+depends on I2C VIDEO_V4L2 SND
+ select FW_LOADER
+ ---help---
+ Choose Y here if you have this FM radio chip.
+
+ In order to control your radio card, you will need to use programs
+ that are compatible with the Video For Linux 2 API. Information on
+ this API and pointers to v4l2 programs may be found at
+ file:Documentation/video4linux/API.html.
+
+ To compile this driver as a module, choose M here: the
+ module will be called radio-wl1273.
+
endif # RADIO_ADAPTERS
diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile
index f615583..d297074 100644
--- a/drivers/media/radio/Makefile
+++ b/drivers/media/radio/Makefile
@@ -26,5 +26,6 @@ obj-$(CONFIG_RADIO_TEA5764) += radio-tea5764.o
obj-$(CONFIG_RADIO_SAA7706H) += saa7706h.o
obj-$(CONFIG_RADIO_TEF6862) += tef6862.o
obj-$(CONFIG_RADIO_TIMBERDALE) += radio-timb.o
+obj-$(CONFIG_RADIO_WL1273) += radio-wl1273.o
EXTRA_CFLAGS += -Isound
diff --git a/drivers/media/radio/radio-wl1273.c
b/drivers/media/radio/radio-wl1273.c
new file mode 100644
index 000..f19b100
--- /dev/null
+++ b/drivers/media/radio/radio-wl1273.c
@@ -0,0 +1,1876 @@
+/*
+ * Driver for the Texas Instruments WL1273 FM radio.
+ *
+ * Copyright (C) Nokia Corporation
+ * Author: Matti J. Aaltonen matti.j.aalto...@nokia.com
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#undef DEBUG
+
+#include asm/unaligned.h
+#include linux/delay.h
+#include linux/firmware.h
+#include linux/mfd/wl1273-core.h
+#include linux/platform_device.h
+#include media/v4l2-common.h
+#include media/v4l2-device.h
+#include media/v4l2-ioctl.h
+
+#define DRIVER_DESC Wl1273 FM Radio - V4L2
+
+#define WL1273_POWER_SET_OFF 0
+#define WL1273_POWER_SET_FM (1 0)
+#define WL1273_POWER_SET_RDS (1 1)
+#define WL1273_POWER_SET_RETENTION (1 4)
+
+#define WL1273_PUPD_SET_OFF 0x00
+#define WL1273_PUPD_SET_ON 0x01
+#define WL1273_PUPD_SET_RETENTION0x10
+
+#define WL1273_FREQ_MULT (1 / 625)
+#define WL1273_INV_FREQ_MULT (625 / 1)
+/*
+ * static unsigned char radio_band - Band
+ *
+ * The bands are 0=Japan, 1=USA-Europe. USA-Europe is the default.
+ */
+static unsigned char radio_band = 1;
+module_param(radio_band, byte, 0);
+MODULE_PARM_DESC(radio_band, Band: 0=Japan, 1=USA-Europe*);
+
+/*
+ * static int radio_nr - The number of the radio device
+ *
+ * The default is 0.
+ */
+static int radio_nr = -1;
+module_param(radio_nr, int, 0);
+MODULE_PARM_DESC(radio_nr, Radio Nr);
+
+struct wl1273_device {
+ struct v4l2_device v4l2dev;
+ struct video_device videodev;
+ struct device *dev;
+ struct wl1273_core *core;
+ bool rds_on;
+};
+
+static int wl1273_fm_set_tx_freq(struct wl1273_core *core, unsigned int freq)
+{
+ int r = 0;
+
+ if (freq core-bands[core-band].bottom_frequency) {
+ dev_err(core-i2c_dev-dev,
+ Frequency out of range: %d %d\n,
+ freq, core-bands[core-band].bottom_frequency);
+ return -EDOM;
+ }
+
+ if (freq core-bands[core-band].top_frequency) {
+ dev_err(core-i2c_dev-dev,
+ Frequency out of range: %d %d\n,
+ freq, core-bands[core-band].top_frequency);
+
PROBLEM: 2.6.34-rc7 kernel panics BUG: unable to handle kernel NULL pointer dereference at (null) while channel scan running
Hi there, When i try to scan for available DBV-S channels kernel panics: BUG: unable to handle kernel NULL pointer dereference at (null) I'm trying to setup a TV box. Contains an Intel Atom N270 CPU, 2GB RAM, 1 TB SATA Hard-Drive. Mainboard is a MSI IM-945GSE Mini-ITX motherboard. The DVB-S card is a WinTV Nexus-S Rev 2.3 card. Kernel is a custom built kernel: Linux version 2.6.34-rc7 (r...@filmdose) (gcc version 4.4.4 (Debian 4.4.4-1) ) #7 SMP Fri May 21 18:06:19 CEST 2010 Channel scan starts fine, finds some channels and after a random duration it crashes. I already tried starting the kernel with nosmp, noapic, and noacpi options but that does not change anything. Kernel trace: --- [ 773.280361] IP: [f825a7ba] saa7146_buffer_next+0x5e/0x1ed [saa7146_vv] [ 773.280361] *pde = [ 773.280361] Oops: [#1] SMP [ 773.280361] last sysfs file: /sys/module/nfsd/initstate [ 773.280361] Modules linked in: nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc f71882fg coretemp loop lnbp21 stv0299 dvb_ttpci snd_hda_codec_realtek dvb_core saa7146_vv videodev v4l1_compat snd_hda_intel saa7146 snd_hda_codec videobuf_dma_sg snd_hwdep videobuf_core snd_pcm i2c_i801 ttpci_eeprom psmouse snd_timer intel_agp evdev pcspkr snd i2c_core serio_raw agpgart video processor rng_core soundcore button output snd_page_alloc usb_storage uhci_hcd ehci_hcd thermal sd_mod crc_t10dif thermal_sys usbcore nls_base e1000e [last unloaded: scsi_wait_scan] [ 773.280361] [ 773.280361] Pid: 0, comm: swapper Not tainted 2.6.34-rc7 #7 A9830IMS/A9830IMS [ 773.280361] EIP: 0060:[f825a7ba] EFLAGS: 00010246 CPU: 0 [ 773.280361] EIP is at saa7146_buffer_next+0x5e/0x1ed [saa7146_vv] [ 773.280361] EAX: f68b3008 EBX: f733d900 ECX: 0001 EDX: 0002 [ 773.280361] ESI: ffd4 EDI: f68b3000 EBP: ESP: c135fefc [ 773.280361] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 773.280361] Process swapper (pid: 0, ti=c135e000 task=c138cb60 task.ti=c135e000) [ 773.280361] Stack: [ 773.280361] f68b3000 f733d900 c13640bc 000a f825e5f6 f733d900 fff7fbf7 f825a759 [ 773.280361] 0 f733d900 f812bdfc fff7fbf7 f6a1e240 c106793a [ 773.280361] 0 c1364080 000a c13640bc c135ff80 c1069072 000a 000a [ 773.280361] Call Trace: [ 773.280361] [f825e5f6] ? vbi_irq_done+0x99/0x9f [saa7146_vv] [ 773.280361] [f825a759] ? vv_callback+0x10f/0x112 [saa7146_vv] [ 773.280361] [f812bdfc] ? interrupt_hw+0x9f/0x1a8 [saa7146] [ 773.280361] [c106793a] ? handle_IRQ_event+0x49/0xe7 [ 773.280361] [c1069072] ? handle_level_irq+0x55/0x9e [ 773.280361] [c10044cb] ? handle_irq+0x17/0x1c [ 773.280361] [c1003da9] ? do_IRQ+0x38/0x8e [ 773.280361] [c1002d30] ? common_interrupt+0x30/0x38 [ 773.280361] [c10086e6] ? mwait_idle+0x59/0x5e [ 773.280361] [c1001ae7] ? cpu_idle+0x91/0xaa [ 773.280361] [c13b9881] ? start_kernel+0x31c/0x321 [ 773.280361] Code: 50 fc 25 f8 e8 9d 0e 01 c9 83 c4 1c 8b 43 44 89 c2 c1 fa 08 38 c2 75 04 0f 0b eb fe 8b 77 08 8d 47 08 39 c6 74 6b 83 ee 2c 31 ed 8b 4e 2c 8b 56 30 89 51 04 89 0a c7 46 2c 00 01 10 00 c7 46 30 [ 773.280361] EIP: [f825a7ba] saa7146_buffer_next+0x5e/0x1ed [saa7146_vv] SS:ESP 0068:c135fefc [ 773.280361] CR2: [ 773.985900] ---[ end trace ec43c18100749f7e ]--- [ 773.999765] Kernel panic - not syncing: Fatal exception in interrupt [ 774.018832] Pid: 0, comm: swapper Tainted: G D2.6.34-rc7 #7 [ 774.037908] Call Trace: [ 774.045272] [c126b5c4] ? panic+0x37/0xa8 [ 774.057844] [c10050e0] ? oops_end+0x88/0x93 [ 774.071195] [c1019bfd] ? no_context+0x10d/0x116 [ 774.085581] [c1019f62] ? do_page_fault+0x0/0x242 [ 774.100232] [c1019d04] ? bad_area_nosemaphore+0xa/0xc [ 774.116194] [c126d6c3] ? error_code+0x73/0x78 [ 774.130077] [f825a7ba] ? saa7146_buffer_next+0x5e/0x1ed [saa7146_vv] [ 774.149941] [f825e5f6] ? vbi_irq_done+0x99/0x9f [saa7146_vv] [ 774.167718] [f825a759] ? vv_callback+0x10f/0x112 [saa7146_vv] [ 774.185762] [f812bdfc] ? interrupt_hw+0x9f/0x1a8 [saa7146] [ 774.203023] [c106793a] ? handle_IRQ_event+0x49/0xe7 [ 774.218459] [c1069072] ? handle_level_irq+0x55/0x9e [ 774.233890] [c10044cb] ? handle_irq+0x17/0x1c [ 774.247758] [c1003da9] ? do_IRQ+0x38/0x8e [ 774.260590] [c1002d30] ? common_interrupt+0x30/0x38 [ 774.276023] [c10086e6] ? mwait_idle+0x59/0x5e [ 774.289890] [c1001ae7] ? cpu_idle+0x91/0xaa [ 774.303243] [c13b9881] ? start_kernel+0x31c/0x321 I can easily reproduce this panic using following command: scan -v /usr/share/dvb/dvb-s/Astra-19.2E Environment: scripts/ver_linux output: Linux filmdose 2.6.34-rc7 #7 SMP Fri May 21 18:06:19 CEST 2010 i686 GNU/Linux Gnu C 4.4.4 Gnu make 3.81 binutils 2.20.1 util-linux scripts/ver_linux: 23: fdformat: not found mount support
Re: Idea of a v4l - fb interface driver
On Sat, May 29, 2010 at 6:06 AM, Ville Syrjälä syrj...@sci.fi wrote: On Fri, May 28, 2010 at 03:41:46PM -0400, Alex Deucher wrote: On Fri, May 28, 2010 at 3:15 PM, Florian Tobias Schandinat If he wants different (independent) content on each output, just provide multiple /dev/fbX devices. I admit that we could use a controlling interface here that decides which user (application) might draw at a time to the interface which they currently only do if they are the active VT. If you want 2 or more outputs to be merged as one just configure this in the driver. The only thing that is impossible to do in fbdev is controlling 2 or more independent display outputs that access the same buffer. But that's not an issue I think. The things above only could use a unification of how to set them up on module load time (as only limited runtime changes are permited given that we must always be able to support a mode that we once entered during runtime). What about changing outputs on the fly (turn off VGA, turn on DVI, switch between multi-head and single-head, etc) or encoders shared between multiple connectors (think a single dac shared between a VGA and a TV port); how do you expose them easily as separate fbdevs? Lots of stuff is doable with fbdev, but it's nicer with kms. But actually getting your data onto the screen is a lot easier with fbdev. There's no standard API in drm to actually allocate the framebuffer and manipulate it. You always need a user space driver to go along with the kernel bits. I'm not saying fbdev is better than drm/kms but at least it can be used to write simple applications that work across different hardware. Perhaps that's something that should be addressed in the drm API. http://www.mail-archive.com/dri-de...@lists.sourceforge.net/msg48461.html I started writing a dumb API for KMS, it got stuck on whether to expose cursors or not, I must dig out the branch. It basically was a create + map API. I'll see if I can get it finished off. The main reason we avoided a fully generic interface is there isn't really a generic way to abstract acceleration on a modern GPU, and buffer allocation on most modern GPUs doesn't want a linear simple buffer. We felt doing a compromised generic interface would lead people down the wrong path into believing they could easily move from the dumb interface to a real accelerated one. There is a userspace library called libkms that abstracts this stuff, but I'd like to just have the kernel do it. Dave. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] tm6000: rewrite init and fini
From: Stefan Ringel stefan.rin...@arcor.de
rewrite tm6000_audio_init and tm6000_audio_fini
Signed-off-by: Stefan Ringel stefan.rin...@arcor.de
---
drivers/staging/tm6000/tm6000-alsa.c | 127 +-
drivers/staging/tm6000/tm6000.h | 15
2 files changed, 63 insertions(+), 79 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-alsa.c
b/drivers/staging/tm6000/tm6000-alsa.c
index ce081cd..477dd78 100644
--- a/drivers/staging/tm6000/tm6000-alsa.c
+++ b/drivers/staging/tm6000/tm6000-alsa.c
@@ -35,29 +35,6 @@
} while (0)
/
- Data type declarations - Can be moded to a header file later
- /
-
-struct snd_tm6000_card {
- struct snd_card*card;
-
- spinlock_t reg_lock;
-
- atomic_t count;
-
- unsigned int period_size;
- unsigned int num_periods;
-
- struct tm6000_core *core;
- struct tm6000_buffer *buf;
-
- intbufsize;
-
- struct snd_pcm_substream *substream;
-};
-
-
-/
Module global static vars
/
@@ -311,21 +288,6 @@ static struct snd_pcm_ops snd_tm6000_pcm_ops = {
/*
* create a PCM device
*/
-static int __devinit snd_tm6000_pcm(struct snd_tm6000_card *chip,
- int device, char *name)
-{
- int err;
- struct snd_pcm *pcm;
-
- err = snd_pcm_new(chip-card, name, device, 0, 1, pcm);
- if (err 0)
- return err;
- pcm-private_data = chip;
- strcpy(pcm-name, name);
- snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_CAPTURE, snd_tm6000_pcm_ops);
-
- return 0;
-}
/* FIXME: Control interface - How to control volume/mute? */
@@ -336,73 +298,64 @@ static int __devinit snd_tm6000_pcm(struct
snd_tm6000_card *chip,
/*
* Alsa Constructor - Component probe
*/
-
-int tm6000_audio_init(struct tm6000_core *dev, int idx)
+int tm6000_audio_init(struct tm6000_core *dev)
{
- struct snd_card *card;
- struct snd_tm6000_card *chip;
- int rc, len;
- charcomponent[14];
+ struct snd_card *card;
+ struct snd_tm6000_card *chip;
+ int rc;
+ static int devnr;
+ charcomponent[14];
+ struct snd_pcm *pcm;
+
+ if (!dev)
+ return 0;
- if (idx = SNDRV_CARDS)
+ if (devnr = SNDRV_CARDS)
return -ENODEV;
- if (!enable[idx])
+ if (!enable[devnr])
return -ENOENT;
- rc = snd_card_create(index[idx], id[idx], THIS_MODULE, 0, card);
+ rc = snd_card_create(index[devnr], id[devnr], THIS_MODULE, 0, card);
if (rc 0) {
- snd_printk(KERN_ERR cannot create card instance %d\n, idx);
+ snd_printk(KERN_ERR cannot create card instance %d\n, devnr);
return rc;
}
- chip = kzalloc(sizeof(*chip), GFP_KERNEL);
+ chip = kzalloc(sizeof(struct snd_tm6000_card), GFP_KERNEL);
if (!chip) {
rc = -ENOMEM;
goto error;
}
- chip-core = dev;
- chip-card = card;
-
- strcpy(card-driver, tm6000-alsa);
sprintf(component, USB%04x:%04x,
le16_to_cpu(dev-udev-descriptor.idVendor),
le16_to_cpu(dev-udev-descriptor.idProduct));
- snd_component_add(card, component);
-
- if (dev-udev-descriptor.iManufacturer)
- len = usb_string(dev-udev,
-dev-udev-descriptor.iManufacturer,
-card-longname, sizeof(card-longname));
- else
- len = 0;
-
- if (len 0)
- strlcat(card-longname, , sizeof(card-longname));
+ snd_component_add(card, component);
- strlcat(card-longname, card-shortname, sizeof(card-longname));
-
- len = strlcat(card-longname, at , sizeof(card-longname));
-
- if (len sizeof(card-longname))
- usb_make_path(dev-udev, card-longname + len,
- sizeof(card-longname) - len);
-
- strlcat(card-longname,
- dev-udev-speed == USB_SPEED_LOW ? , low speed :
- dev-udev-speed == USB_SPEED_FULL ? , full speed :
- , high speed,
- sizeof(card-longname));
-
- rc = snd_tm6000_pcm(chip, 0, tm6000 Digital);
+ spin_lock_init(chip-reg_lock);
+ rc = snd_pcm_new(card, TM6000 Audio, 0, 0, 1, pcm);
if (rc
[PATCH 3/3] tm6000: move dvb into a separate kern module
From: Stefan Ringel stefan.rin...@arcor.de
move dvb into a separate kern module
Signed-off-by: Stefan Ringel stefan.rin...@arcor.de
---
drivers/staging/tm6000/Kconfig|4 +-
drivers/staging/tm6000/Makefile |5 +--
drivers/staging/tm6000/tm6000-cards.c | 31 +---
drivers/staging/tm6000/tm6000-core.c |1 +
drivers/staging/tm6000/tm6000-dvb.c | 83 -
drivers/staging/tm6000/tm6000.h |1 +
6 files changed, 89 insertions(+), 36 deletions(-)
diff --git a/drivers/staging/tm6000/Kconfig b/drivers/staging/tm6000/Kconfig
index 3657e33..c725356 100644
--- a/drivers/staging/tm6000/Kconfig
+++ b/drivers/staging/tm6000/Kconfig
@@ -26,8 +26,8 @@ config VIDEO_TM6000_ALSA
module will be called tm6000-alsa.
config VIDEO_TM6000_DVB
- bool DVB Support for tm6000 based TV cards
- depends on VIDEO_TM6000 DVB_CORE EXPERIMENTAL
+ tristate DVB Support for tm6000 based TV cards
+ depends on VIDEO_TM6000 DVB_CORE USB EXPERIMENTAL
select DVB_ZL10353
---help---
This adds support for DVB cards based on the tm5600/tm6000 chip.
diff --git a/drivers/staging/tm6000/Makefile b/drivers/staging/tm6000/Makefile
index 93370fc..4129c18 100644
--- a/drivers/staging/tm6000/Makefile
+++ b/drivers/staging/tm6000/Makefile
@@ -4,12 +4,9 @@ tm6000-objs := tm6000-cards.o \
tm6000-video.o \
tm6000-stds.o
-ifeq ($(CONFIG_VIDEO_TM6000_DVB),y)
-tm6000-objs += tm6000-dvb.o
-endif
-
obj-$(CONFIG_VIDEO_TM6000) += tm6000.o
obj-$(CONFIG_VIDEO_TM6000_ALSA) += tm6000-alsa.o
+obj-$(CONFIG_VIDEO_TM6000_DVB) += tm6000-dvb.o
EXTRA_CFLAGS = -Idrivers/media/video
EXTRA_CFLAGS += -Idrivers/media/common/tuners
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index 553ebe4..87b0bc4 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -346,7 +346,7 @@ int tm6000_xc5000_callback(void *ptr, int component, int
command, int arg)
}
return (rc);
}
-
+EXPORT_SYMBOL_GPL(tm6000_xc5000_callback);
/* Tuner callback to provide the proper gpio changes needed for xc2028 */
@@ -436,6 +436,7 @@ int tm6000_tuner_callback(void *ptr, int component, int
command, int arg)
}
return rc;
}
+EXPORT_SYMBOL_GPL(tm6000_tuner_callback);
int tm6000_cards_setup(struct tm6000_core *dev)
{
@@ -693,31 +694,12 @@ static int tm6000_init_dev(struct tm6000_core *dev)
goto err;
tm6000_add_into_devlist(dev);
-
tm6000_init_extension(dev);
- if (dev-caps.has_dvb) {
- dev-dvb = kzalloc(sizeof(*(dev-dvb)), GFP_KERNEL);
- if (!dev-dvb) {
- rc = -ENOMEM;
- goto err2;
- }
-
-#ifdef CONFIG_VIDEO_TM6000_DVB
- rc = tm6000_dvb_register(dev);
- if (rc 0) {
- kfree(dev-dvb);
- dev-dvb = NULL;
- goto err2;
- }
-#endif
}
mutex_unlock(dev-lock);
return 0;
-err2:
- v4l2_device_unregister(dev-v4l2_dev);
-
err:
mutex_unlock(dev-lock);
return rc;
@@ -918,13 +900,6 @@ static void tm6000_usb_disconnect(struct usb_interface
*interface)
mutex_lock(dev-lock);
-#ifdef CONFIG_VIDEO_TM6000_DVB
- if (dev-dvb) {
- tm6000_dvb_unregister(dev);
- kfree(dev-dvb);
- }
-#endif
-
if (dev-gpio.power_led) {
switch (dev-model) {
case TM6010_BOARD_HAUPPAUGE_900H:
@@ -954,8 +929,8 @@ static void tm6000_usb_disconnect(struct usb_interface
*interface)
usb_put_dev(dev-udev);
- tm6000_remove_from_devlist(dev);
tm6000_close_extension(dev);
+ tm6000_remove_from_devlist(dev);
mutex_unlock(dev-lock);
kfree(dev);
diff --git a/drivers/staging/tm6000/tm6000-core.c
b/drivers/staging/tm6000/tm6000-core.c
index b5965a8..cd87b14 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@ -396,6 +396,7 @@ int tm6000_init_digital_mode (struct tm6000_core *dev)
return 0;
}
+EXPORT_SYMBOL(tm6000_init_digial_mode);
struct reg_init {
u8 req;
diff --git a/drivers/staging/tm6000/tm6000-dvb.c
b/drivers/staging/tm6000/tm6000-dvb.c
index b9e9ef1..7830826 100644
--- a/drivers/staging/tm6000/tm6000-dvb.c
+++ b/drivers/staging/tm6000/tm6000-dvb.c
@@ -38,6 +38,19 @@
dev-name, __FUNCTION__, ##arg);\
} while (0)
+MODULE_DESCRIPTION(DVB driver extension module for tm5600/6000/6010 based TV
cards);
+MODULE_AUTHOR(Mauro Carvalho Chehab mche...@redhat.com);
+MODULE_LICENSE(GPL);
+
+MODULE_SUPPORTED_DEVICE({{Trident, tm5600},
+ {{Trident, tm6000},
+ {{Trident, tm6010});
+
+static int debug
+
Re: ir-core multi-protocol decode and mceusb
Em 29-05-2010 23:24, Jarod Wilson escreveu: On Sat, May 29, 2010 at 4:01 PM, Andy Walls awa...@md.metrocast.net wrote: On Sat, 2010-05-29 at 12:58 -0400, Jarod Wilson wrote: On Sat, May 29, 2010 at 8:39 AM, Andy Walls awa...@md.metrocast.net wrote: On Fri, 2010-05-28 at 00:47 -0400, Jarod Wilson wrote: So I'm inching closer to a viable mceusb driver submission -- both a first-gen and a third-gen transceiver are now working perfectly with multiple different mce remotes. However, that's only when I make sure the mceusb driver is loaded w/only the rc6 decoder loaded. When ir-core comes up, it requests all decoders to load, starting with the nec decoder, followed by the rc5 decoder, then the rc6 decoder and so on (init_decoders() in ir-raw-event.c). When I call ir_raw_event_handle, all decoders get run on the ir data buffer, starting with nec. Well, the nec decoder doesn't like the rc6 data, so it pukes. The RUN_DECODER macro break's out of the routine when that happens, and the rc6 decoder never gets a chance to run. (Similarly, if only ir-nec-decoder has been removed, the rc5 decoder pukes on the rc6 data, same problem). Yes, if the system kernel is going to attempt to discriminate between various input singals, it needs to let all its correlators run and produce a confidence number from each. Then ideally one would take the result with the highest confidence. Right now it looks like all the confidence determinations are boolean (0 or -EINVAL) and there is no chance to deal with the case that two different decoders validly decode something. The first decoder that declares a match wins and sends an event. Yeah, it does look that way. I wonder how likely it is that e.g. a valid RC6 signal would be decoded to something by say the NEC decoder, NEC is a pulse position code and RC-6 is manchester encoded, so that particular case would be unlikely. I would think one would have a better chance of false positiive detections between similar encoding types: pulse position, pulse width, or manchester. Looking at slide 11 of this: http://www.audiodevelopers.com/temp/Remote_Controls.ppt It looks like the pulse position protocols with a header space of 8T (where 8T is about 4ms) would be the only ones that could get confused. Since these are streaming decoders, it looks like JVC would come up with false detections first, since it has the shortest payload of the pulse position protocols. I think JVC will always claim to decode an NEC pulse train. (I'll try to test that sometime.) with a resulting value that matched an entry in the (RC6) keymap loaded for the remote... Certainly seems like something that *could* happen somehow, but probably unlikely? I dunno... I don't know either. There appears to be a chance for the first 16 bits of a transmitted NEC (Addr:Addr') or Extended NEC (AddrHi:AddrLo) sequence, to be interpreted as JVC (Addr:Cmd), and the JVC decoder matching a scancode in the keytable for the NEC remote. We do have the option to disable all but the relevant protocol handler on a per-device basis though, if that's a problem. Hrm, the key tables also have a protocol tied to them, not sure if that's taken into account when doing matching... Still getting to know the code. :) It does not look like ir_keydown() ir_g_keycode_from_table() ir_getkeycode() bother to check the ir_type (e.g. IR_TYPE_NEC) of the keymap against the decoders type. Neither do the decoders themselves. If a decoder decodes something and thinks its valid, it tries to send a key event with ir_keydown(). ir_keydown() won't send a key event if the lookup comes back KEY_RESERVED, but it doesn't tell the decoder about the failure to find a key mapping. A decoder can come back saying it did it's job, without knowing whether or not the decoding corresponded to a valid key in the loaded keymap. :( You will have to deal with the case that two or more decoders may match and each sends an IR event. (Unless the ir-core already deals with this somehow...) Well, its gotta decode correctly to a value, and then match a value in the loaded key table for an input event to get sent through. At least for the RC6 MCE remotes, I haven't seen any of the other decoders take the signal and interpret it as valid -- which ought to be by design, if you consider that people use several different remotes with varying ir signals with different devices all receiving them all the time without problems (usually). And if we're not already, we could likely add some logic to give higher precedence to values arrived at using the protocol decoder that matches the key table we've got loaded for a given device. After looking at things, the only potential problem I can see right now is with the JVC decoder and NEC remotes. I think that problem is most easily eliminated either by a. having ir_keydown() (or the functions
Re: schedule inside spin_lock_irqsave?
On 05/30/2010 04:52 PM, Richard Zidlicky wrote:
Hi,
came across following snippet of code
(2.6.34:drivers/media/dvb/siano/smscoreapi.c) and
since prepare_to_wait is new for me I am wondering if this is can work?
struct smscore_buffer_t *smscore_getbuffer(struct smscore_device_t *coredev)
{
struct smscore_buffer_t *cb = NULL;
unsigned long flags;
DEFINE_WAIT(wait);
spin_lock_irqsave(coredev-bufferslock, flags);
/* This function must return a valid buffer, since the buffer list is
* finite, we check that there is an available buffer, if not, we wait
* until such buffer become available.
*/
prepare_to_wait(coredev-buffer_mng_waitq, wait, TASK_INTERRUPTIBLE);
if (list_empty(coredev-buffers))
schedule();
finish_wait(coredev-buffer_mng_waitq, wait);
cb = (struct smscore_buffer_t *) coredev-buffers.next;
list_del(cb-entry);
spin_unlock_irqrestore(coredev-bufferslock, flags);
Yep, that's a double bug.
1) If the waiting is interrupted, it will die because the list is still
empty.
2) If there is no entry in the list, it will deadlock at least on UP.
This should be
wait_event(coredev-buffer_mng_waitq, cb = get_entry());
with get_entry like:
struct smscore_buffer_t *get_entry(void)
{
struct smscore_buffer_t *cb = NULL;
spin_lock_irqsave(coredev-bufferslock, flags);
if (!list_empty(coredev-buffers)) {
cb = (struct smscore_buffer_t *) coredev-buffers.next;
list_del(cb-entry);
}
spin_unlock_irqrestore(coredev-bufferslock, flags);
return cb;
}
regards,
--
js
--
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: What ever happened to standardizing signal level?
On Sunday 30 May 2010 17:18:25 Michael Krufky wrote: Hans Verkuil wrote: On Sunday 30 May 2010 09:07:46 VDR User wrote: On Sat, May 29, 2010 at 2:09 AM, Mike Booth mike_boot...@iprimus.com.au wrote: i think someone is too concerned about being precisely accurate. So much so that no-one can see the woods for the trees any more. Its not important to me that accuracy is spot on. I only want to know that when tuning the dish I'm getting \better or worse. I tend to agree with this. Ultimately what's important is not necessarily that the readings are 100% accurate, but rather simply put into some kind of universal scale that provides useful output to the user. Many users were happy to see some activity addressing this issue and unfortunately it seems to have stalled out but I'm not sure why. I honestly felt there was enough common ground being discussed that we'd have a solution by now. To the best of my knowledge Mike Krufky intended to work on this but he clearly no longer has time to do that work. Mike, can you perhaps explain what you wanted to do? Hopefully someone else can find the time to implement it. Regards, Hans ...clearly no longer has time -- please do not speak on my behalf -- I have taken a break from v4l-dvb, and I will return when I have time for it again. My apologies, that was poorly phrased. 'appears to have little time' would have been much better. Sorry about that. I already did a lot of the work for standardizing signal level, but I need to clean it up, consider new demod modules, push trees and send pull requests. Right now, correct -- I don't have time for it. I'll likely get to this by mid-august -- I will have more time again by then. I have a plethora of changes in my queue that I have to burn through and merge, including j-rod's lgdt3304 support. I used to get this stuff done very quickly, but there is a lot of change going on in my life right now... When things settle down here, I'll be back in full force. :-) Looking forward to that! Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- 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: schedule inside spin_lock_irqsave?
On 05/30/2010 05:24 PM, Jiri Slaby wrote:
struct smscore_buffer_t *get_entry(void)
{
struct smscore_buffer_t *cb = NULL;
spin_lock_irqsave(coredev-bufferslock, flags);
if (!list_empty(coredev-buffers)) {
cb = (struct smscore_buffer_t *) coredev-buffers.next;
Looking at the smscore_buffer_t definition, this is really ugly since it
relies on entry being the first in the structure. It should be
list_first_entry(coredev-buffers, ...) instead, cast-less.
list_del(cb-entry);
}
spin_unlock_irqrestore(coredev-bufferslock, flags);
return cb;
}
--
js
--
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: What ever happened to standardizing signal level?
Hans Verkuil wrote: On Sunday 30 May 2010 09:07:46 VDR User wrote: On Sat, May 29, 2010 at 2:09 AM, Mike Booth mike_boot...@iprimus.com.au wrote: i think someone is too concerned about being precisely accurate. So much so that no-one can see the woods for the trees any more. Its not important to me that accuracy is spot on. I only want to know that when tuning the dish I'm getting \better or worse. I tend to agree with this. Ultimately what's important is not necessarily that the readings are 100% accurate, but rather simply put into some kind of universal scale that provides useful output to the user. Many users were happy to see some activity addressing this issue and unfortunately it seems to have stalled out but I'm not sure why. I honestly felt there was enough common ground being discussed that we'd have a solution by now. To the best of my knowledge Mike Krufky intended to work on this but he clearly no longer has time to do that work. Mike, can you perhaps explain what you wanted to do? Hopefully someone else can find the time to implement it. Regards, Hans ...clearly no longer has time -- please do not speak on my behalf -- I have taken a break from v4l-dvb, and I will return when I have time for it again. I already did a lot of the work for standardizing signal level, but I need to clean it up, consider new demod modules, push trees and send pull requests. Right now, correct -- I don't have time for it. I'll likely get to this by mid-august -- I will have more time again by then. I have a plethora of changes in my queue that I have to burn through and merge, including j-rod's lgdt3304 support. I used to get this stuff done very quickly, but there is a lot of change going on in my life right now... When things settle down here, I'll be back in full force. :-) Regards, Mike Krufky Regards, Mike -- 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: What ever happened to standardizing signal level?
Markus Rechberger wrote: Hi, A little bit more ontopic, did anyone get around to read the signallevel of the tda18721? I wonder the register does not return any signallevel as indicated in the specifications. Markus There is a power level value that can be read from the tda18271 -- I had a patch that enabled reading of this value, for testing purposes, but it wasn't as useful as I had hoped, so I never bothered to merge it. If you'd like to play with it, I pushed up some code last year: http://kernellabs.com/hg/~mkrufky/tda18271-pl/rev/4373874cff29 Let me know how this works for you, or if you choose to change it. I If you find it valuable, we can merge it in somehow. Regards, Mike -- 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: What ever happened to standardizing signal level?
- Original Nachricht Von: VDR User user@gmail.com An: hermann pitton hermann-pit...@arcor.de Datum: 30.05.2010 09:01 Betreff: Re: What ever happened to standardizing signal level? On Sat, May 29, 2010 at 10:52 PM, hermann pitton hermann-pit...@arcor.de wrote: ...troll spam removed... Hermann, you're a known troll with clearly nothing to contribute to this thread therefore you're comments are unwelcome. On requests without success http://linuxtv.org/pipermail/linux-dvb/2009-August/032299.html you are well known for being in good company soon. http://linuxtv.org/pipermail/linux-dvb/2008-December/030704.html I wonder, if this will ever change, but hope so. Hermann Und was machen Sie heute abend? Alles Events Ihrer Gegend auf einen Blick im Arcor.de-Veranstaltungskalender: http://www.arcor.de/rd/footer.events -- 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: What ever happened to standardizing signal level?
On Sun, May 30, 2010 at 5:21 PM, Michael Krufky mkru...@linuxtv.org wrote: Markus Rechberger wrote: Hi, A little bit more ontopic, did anyone get around to read the signallevel of the tda18721? I wonder the register does not return any signallevel as indicated in the specifications. Markus There is a power level value that can be read from the tda18271 -- I had a patch that enabled reading of this value, for testing purposes, but it wasn't as useful as I had hoped, so I never bothered to merge it. If you'd like to play with it, I pushed up some code last year: http://kernellabs.com/hg/~mkrufky/tda18271-pl/rev/4373874cff29 Let me know how this works for you, or if you choose to change it. I If you find it valuable, we can merge it in somehow. hmm.. I somewhat tried the same but the register kept flipping back and the powerlevel register returned 0. Markus -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode
On Sunday 30 May 2010 13:34:55 Jean-Francois Moine wrote: On Sat, 29 May 2010 21:32:07 +0200 Ondrej Zary li...@rainbow-software.org wrote: The Color Space/Compression reported by the driver is only one: RGB 24 The driver also uses these files which may (or may not) be related to used compression: iyuv_32.dll, msh263.drv, msyuv.dll, tsbyuv.dll In standalone mode, the camera records video in MJPEG format. Hello Ondrej, Bad news, the images are compressed by an unknown algorithm (unknown from Linux point of vue). The decompression function could be found in some part of the ms-win driver, but: - first, I have no time to search and disassemble this function, - then, I did have this problem with an other webcam (17a1:0118), and after searching for a long time, nobody could find the function, and the driver is in stand-by since 2 years, - eventually, is this legal? That's bad... The driver contains file sp5x_32.dll which is registered in system.ini file as [drivers32] VIDC.SP54=SP5X_32.DLL Seems that the codec is called SP54 - hope that it's used to decompress the data. All I can do is to code the driver and let you or anyone find the decompression function... Maybe we can dump some data, create AVI file from that and try to decode the file using that codec. -- Ondrej Zary -- 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 for 2.6.34] saa7134: add support for Compro VideoMate M1F
Em 26-05-2010 17:30, Pavel Osnova escreveu:
Sorry for the line breakages.
Patch doesn't apply:
$ test_patch
patching file Documentation/video4linux/CARDLIST.saa7134
Hunk #1 FAILED at 176.
1 out of 1 hunk FAILED -- saving rejects to file
Documentation/video4linux/CARDLIST.saa7134.rej
patching file drivers/media/IR/keymaps/Makefile
Hunk #1 FAILED at 61.
1 out of 1 hunk FAILED -- saving rejects to file
drivers/media/IR/keymaps/Makefile.rej
patching file drivers/media/IR/keymaps/rc-videomate-m1f.c
patching file drivers/media/video/saa7134/saa7134-cards.c
Hunk #1 FAILED at 5428.
Hunk #2 FAILED at 6890.
2 out of 2 hunks FAILED -- saving rejects to file
drivers/media/video/saa7134/saa7134-cards.c.rej
patching file drivers/media/video/saa7134/saa7134.h
Hunk #1 FAILED at 303.
1 out of 1 hunk FAILED -- saving rejects to file
drivers/media/video/saa7134/saa7134.h.rej
patching file drivers/media/video/saa7134/saa7134-input.c
Hunk #1 FAILED at 815.
1 out of 1 hunk FAILED -- saving rejects to file
drivers/media/video/saa7134/saa7134-input.c.rej
patching file include/media/rc-map.h
Hunk #1 succeeded at 112 (offset 1 line).
Patch
patches/lmml_102504_for_2_6_34_saa7134_add_support_for_compro_videomate_m1f.patch
doesn't apply
diff -uprN v4l-dvb_orig/Documentation/video4linux/CARDLIST.saa7134
v4l-dvb/Documentation/video4linux/CARDLIST.saa7134
--- v4l-dvb_orig/Documentation/video4linux/CARDLIST.saa7134 2010-05-26
20:34:06.0 +0300
+++ v4l-dvb/Documentation/video4linux/CARDLIST.saa7134 2010-05-26
21:12:28.247684250 +0300
@@ -176,5 +176,6 @@
175 - Leadtek Winfast DTV1000S [107d:6655]
176 - Beholder BeholdTV 505 RDS[:5051]
177 - Hawell HW-404M7
-179 - Beholder BeholdTV H7[5ace:7190]
-180 - Beholder BeholdTV A7[5ace:7090]
+178 - Beholder BeholdTV H7[5ace:7190]
+179 - Beholder BeholdTV A7[5ace:7090]
+180 - Compro VideoMate M1F[185b:c900]
diff -uprN v4l-dvb_orig/drivers/media/IR/keymaps/Makefile
v4l-dvb/drivers/media/IR/keymaps/Makefile
--- v4l-dvb_orig/drivers/media/IR/keymaps/Makefile 2010-05-26
20:34:09.0 +0300
+++ v4l-dvb/drivers/media/IR/keymaps/Makefile 2010-05-26 21:09:41.498117258
+0300
@@ -61,6 +61,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t
rc-terratec-cinergy-xs.o \
rc-tevii-nec.o \
rc-tt-1500.o \
+ rc-videomate-m1f.o \
rc-videomate-s350.o \
rc-videomate-tv-pvr.o \
rc-winfast.o \
diff -uprN v4l-dvb_orig/drivers/media/IR/keymaps/rc-videomate-m1f.c
v4l-dvb/drivers/media/IR/keymaps/rc-videomate-m1f.c
--- v4l-dvb_orig/drivers/media/IR/keymaps/rc-videomate-m1f.c1970-01-01
03:00:00.0 +0300
+++ v4l-dvb/drivers/media/IR/keymaps/rc-videomate-m1f.c 2010-05-26
22:27:31.99335 +0300
@@ -0,0 +1,92 @@
+/* videomate-m1f.h - Keytable for videomate_m1f Remote Controller
+ *
+ * keymap imported from ir-keymaps.c
+ *
+ * Copyright (c) 2010 by Pavel Osnova pvosn...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include media/rc-map.h
+
+static struct ir_scancode videomate_m1f[] = {
+ { 0x01, KEY_POWER },
+ { 0x31, KEY_TUNER },
+ { 0x33, KEY_VIDEO },
+ { 0x2f, KEY_RADIO },
+ { 0x30, KEY_CAMERA },
+ { 0x2d, KEY_NEW }, /* TV record button */
+ { 0x17, KEY_CYCLEWINDOWS },
+ { 0x2c, KEY_ANGLE },
+ { 0x2b, KEY_LANGUAGE },
+ { 0x32, KEY_SEARCH }, /* '...' button */
+ { 0x11, KEY_UP },
+ { 0x13, KEY_LEFT },
+ { 0x15, KEY_OK },
+ { 0x14, KEY_RIGHT },
+ { 0x12, KEY_DOWN },
+ { 0x16, KEY_BACKSPACE },
+ { 0x02, KEY_ZOOM }, /* WIN key */
+ { 0x04, KEY_INFO },
+ { 0x05, KEY_VOLUMEUP },
+ { 0x03, KEY_MUTE },
+ { 0x07, KEY_CHANNELUP },
+ { 0x06, KEY_VOLUMEDOWN },
+ { 0x08, KEY_CHANNELDOWN },
+ { 0x0c, KEY_RECORD },
+ { 0x0e, KEY_STOP },
+ { 0x0a, KEY_BACK },
+ { 0x0b, KEY_PLAY },
+ { 0x09, KEY_FORWARD },
+ { 0x10, KEY_PREVIOUS },
+ { 0x0d, KEY_PAUSE },
+ { 0x0f, KEY_NEXT },
+ { 0x1e, KEY_1 },
+ { 0x1f, KEY_2 },
+ { 0x20, KEY_3 },
+ { 0x21, KEY_4 },
+ { 0x22, KEY_5 },
+ { 0x23, KEY_6 },
+ { 0x24, KEY_7 },
+ { 0x25, KEY_8 },
+ { 0x26, KEY_9 },
+ { 0x2a, KEY_NUMERIC_STAR }, /* * key */
+ { 0x1d, KEY_0 },
+ { 0x29, KEY_SUBTITLE }, /* # key */
+ { 0x27, KEY_CLEAR },
+ { 0x34, KEY_SCREEN },
+ { 0x28,
Re: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode
On Sun, 30 May 2010 19:55:22 +0200
Ondrej Zary li...@rainbow-software.org wrote:
That's bad...
The driver contains file sp5x_32.dll which is registered in
system.ini file as [drivers32]
VIDC.SP54=SP5X_32.DLL
Seems that the codec is called SP54 - hope that it's used to
decompress the data.
All I can do is to code the driver and let you or anyone find the
decompression function...
Maybe we can dump some data, create AVI file from that and try to
decode the file using that codec.
It is easy to get images from the usbsnoop files. I join an image
extracted from your file usbsnoop-video-capture-640x480.log. If you
want more images, they are in IsoPackets. The first 2 bytes of each isoc
packet mean:
- '02 80' or '02 81': first of intermediate part of the image ('0' or
'1' is the image sequence number)
- '02 82' or '02 83': last part of the image
Someone had an idea to try and guess the compression algorithm: do
usbsnoop's with full black and full white images. But this idea did not
work with the other webcam: the images were quite the same!
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
image640.dat
Description: Binary data
Re: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode
On Sun, 2010-05-30 at 13:34 +0200, Jean-Francois Moine wrote: On Sat, 29 May 2010 21:32:07 +0200 Ondrej Zary li...@rainbow-software.org wrote: The Color Space/Compression reported by the driver is only one: RGB 24 The driver also uses these files which may (or may not) be related to used compression: iyuv_32.dll, msh263.drv, msyuv.dll, tsbyuv.dll In standalone mode, the camera records video in MJPEG format. Hello Ondrej, Bad news, the images are compressed by an unknown algorithm (unknown from Linux point of vue). The decompression function could be found in some part of the ms-win driver, but: - first, I have no time to search and disassemble this function, - then, I did have this problem with an other webcam (17a1:0118), and after searching for a long time, nobody could find the function, and the driver is in stand-by since 2 years, - eventually, is this legal? All I can do is to code the driver and let you or anyone find the decompression function... I ran into this with my daughetr's cheap little Sakar webcam based on a Jeilin chip. After some investigation about the chip and learning it being only able to perform JPEG compression, it was rather easy to figure out it was just sending MJPEG data with the headers stripped off. This thread from last year tells most of the story http://www.mail-archive.com/linux-media@vger.kernel.org/msg06766.html (Many thanks to Theodore for doing the legwork on experiments and a new GSPCA driver - jeilinj) Since your camera records MJPEG in stand-alone mode (mine recorded MJPEG in an AVI container in stand-alone mode), it stands to reason, your camera may be doing the same sort of thing. The payload of MJPEG data will look very random since the compressed data is Huffman (entropy) encoded in the final step of encoding. 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
[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:Sun May 30 19:00:24 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14875:304cfde05b3f git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 4fcfa8824391ef0f9cff82122067f31c6d920921 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-armv5: ERRORS linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-armv5-ixp: OK linux-2.6.34-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.34-i686: ERRORS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-m32r: ERRORS linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-mips: ERRORS linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK linux-2.6.34-x86_64: ERRORS linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-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/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode
On Sun, 2010-05-30 at 19:55 +0200, Ondrej Zary wrote: On Sunday 30 May 2010 13:34:55 Jean-Francois Moine wrote: On Sat, 29 May 2010 21:32:07 +0200 Ondrej Zary li...@rainbow-software.org wrote: The Color Space/Compression reported by the driver is only one: RGB 24 The driver also uses these files which may (or may not) be related to used compression: iyuv_32.dll, msh263.drv, msyuv.dll, tsbyuv.dll In standalone mode, the camera records video in MJPEG format. Hello Ondrej, Bad news, the images are compressed by an unknown algorithm (unknown from Linux point of vue). The decompression function could be found in some part of the ms-win driver, but: - first, I have no time to search and disassemble this function, - then, I did have this problem with an other webcam (17a1:0118), and after searching for a long time, nobody could find the function, and the driver is in stand-by since 2 years, - eventually, is this legal? That's bad... The driver contains file sp5x_32.dll which is registered in system.ini file as [drivers32] VIDC.SP54=SP5X_32.DLL Seems that the codec is called SP54 - hope that it's used to decompress the data. All I can do is to code the driver and let you or anyone find the decompression function... SP54 is Sunplus' ( http://www.sunplus.com.tw/ ) FourCC code for a version of MJPEG with the headers removed according to http://www.fourcc.org/ Maybe we can dump some data, create AVI file from that and try to decode the file using that codec. FourCC.org points to this page: http://libland.fr.st/download.html which points to a utility to conver the data back into an MJPEG: http://mxhaard.free.fr/spca50x/Download/sp54convert.tar.gz I have no idea if any of the above is true, 'cause I read it on the Internet. ;) 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
Re: ir-core multi-protocol decode and mceusb
On Sun, May 30, 2010 at 10:02 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 29-05-2010 23:24, Jarod Wilson escreveu: On Sat, May 29, 2010 at 4:01 PM, Andy Walls awa...@md.metrocast.net wrote: ... We do have the option to disable all but the relevant protocol handler on a per-device basis though, if that's a problem. Hrm, the key tables also have a protocol tied to them, not sure if that's taken into account when doing matching... Still getting to know the code. :) It does not look like ir_keydown() ir_g_keycode_from_table() ir_getkeycode() bother to check the ir_type (e.g. IR_TYPE_NEC) of the keymap against the decoders type. Neither do the decoders themselves. If a decoder decodes something and thinks its valid, it tries to send a key event with ir_keydown(). ir_keydown() won't send a key event if the lookup comes back KEY_RESERVED, but it doesn't tell the decoder about the failure to find a key mapping. A decoder can come back saying it did it's job, without knowing whether or not the decoding corresponded to a valid key in the loaded keymap. :( You will have to deal with the case that two or more decoders may match and each sends an IR event. (Unless the ir-core already deals with this somehow...) Well, its gotta decode correctly to a value, and then match a value in the loaded key table for an input event to get sent through. At least for the RC6 MCE remotes, I haven't seen any of the other decoders take the signal and interpret it as valid -- which ought to be by design, if you consider that people use several different remotes with varying ir signals with different devices all receiving them all the time without problems (usually). And if we're not already, we could likely add some logic to give higher precedence to values arrived at using the protocol decoder that matches the key table we've got loaded for a given device. After looking at things, the only potential problem I can see right now is with the JVC decoder and NEC remotes. I think that problem is most easily eliminated either by a. having ir_keydown() (or the functions it calls) check to see that the decoder matches the loaded keymap, or b. only calling the decoder that matches the loaded keymap's protocol Of the above, b. saves processor cycles and frees up the global ir_raw_handler spin lock sooner. That spin lock is serializing pulse decoding for all the IR receivers in the system (pulse decoding can still be interleaved, just only one IR receiver's pulses are be processed at any time). What's the point of running decoders that should never match the loaded keymap? For the daily use case where a known-good keymap is in place, I'm coming to the conclusion that there's no point, we're only wasting resources. For initial figure out what this remote is type of stuff, running all decoders makes sense. One thought I had was that perhaps we start by running through the decoder that is listed in the keymap. If it decodes to a scancode and we find a valid key in the key table (i.e., not KEY_RESERVED), we're done. If decoding fails or we don't find a valid key, then try the other decoders. However, this is possibly also wasteful -- most people with any somewhat involved htpc setup are going to be constantly sending IR signals intended for other devices that we pick up and try to decode. So I'd say we go with your option b, and only call the decoder that matches the loaded keymap. One could either pass in a modparam or twiddle a sysfs attr or use ir-keytable to put the receiver into a mode that called all decoders -- i.e., set protocol to IR_TYPE_UNKNOWN, with the intention being to figure it out based on running all decoders, and create a new keymap where IR_TYPE_FOO is known. There's no need to extra parameters. Decoders can be disabled by userspace, per each rc sysfs node. Btw, the current version of ir-keytable already sets the enabled protocols based on the protocol reported by the rc keymap. What it makes sense is to add a patch at RC core that will properly enable/disable the protocols based on IR_TYPE, when the rc-map is stored in-kernel. Ah, yeah, that does make sense. And if we add that, ir-keytable doesn't actually have to worry about doing similar itself any longer. If you're not already working on it, I can try to whip something up, though I'm knee-deep in an ir-lirc-codec bridge 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
Re: [PATCH for 2.6.34] saa7134: add support for Compro VideoMate M1F
Hi,
- Original Nachricht
Von: Mauro Carvalho Chehab mche...@redhat.com
An: Pavel Osnova pvosn...@gmail.com
Datum: 30.05.2010 20:05
Betreff: Re: [PATCH for 2.6.34] saa7134: add support for Compro VideoMate
M1F
Em 26-05-2010 17:30, Pavel Osnova escreveu:
Sorry for the line breakages.
Patch doesn't apply:
Pavel, please send a new version against current.
You diff against changes not documented in the master repo.
We also better would know, which tuner is on it exactly.
We can expect at least three different ones.
PAL/SECAM, NTSC/System-M and Japan.
http://www.comprousa.com/en/product/m1f/m1f-Specifications.html
The tuner size is small, like a MK5, but you say LG API is fine, even on UHF
and no tda9886.
It is not a LG PAL NEW TAPC, just something compatible I guess.
Then they would have a lot of different tuners for the PAL/SECAM region, like
in the old days.
A little hard to believe, without knowing more about chips and filters on that
tuner, or at least
that something under the Compro sticker says Pal BG/DK only or so, which would
make us aware to
expect different tuners on PAL-I, SECAM etc.
http://www.comprousa.com/en/product/m1f/m1f-hardware.html
Please also identify the IR decoder chip and its xtal, the blue RF filter and
the chip above it.
Cheers,
Hermann
$ test_patch
patching file Documentation/video4linux/CARDLIST.saa7134
Hunk #1 FAILED at 176.
1 out of 1 hunk FAILED -- saving rejects to file
Documentation/video4linux/CARDLIST.saa7134.rej
patching file drivers/media/IR/keymaps/Makefile
Hunk #1 FAILED at 61.
1 out of 1 hunk FAILED -- saving rejects to file
drivers/media/IR/keymaps/Makefile.rej
patching file drivers/media/IR/keymaps/rc-videomate-m1f.c
patching file drivers/media/video/saa7134/saa7134-cards.c
Hunk #1 FAILED at 5428.
Hunk #2 FAILED at 6890.
2 out of 2 hunks FAILED -- saving rejects to file
drivers/media/video/saa7134/saa7134-cards.c.rej
patching file drivers/media/video/saa7134/saa7134.h
Hunk #1 FAILED at 303.
1 out of 1 hunk FAILED -- saving rejects to file
drivers/media/video/saa7134/saa7134.h.rej
patching file drivers/media/video/saa7134/saa7134-input.c
Hunk #1 FAILED at 815.
1 out of 1 hunk FAILED -- saving rejects to file
drivers/media/video/saa7134/saa7134-input.c.rej
patching file include/media/rc-map.h
Hunk #1 succeeded at 112 (offset 1 line).
Patch
patches/lmml_102504_for_2_6_34_saa7134_add_support_for_compro_videomate_m1f.
patch doesn't apply
diff -uprN v4l-dvb_orig/Documentation/video4linux/CARDLIST.saa7134
v4l-dvb/Documentation/video4linux/CARDLIST.saa7134
--- v4l-dvb_orig/Documentation/video4linux/CARDLIST.saa7134 2010-05-26
20:34:06.0 +0300
+++ v4l-dvb/Documentation/video4linux/CARDLIST.saa7134 2010-05-26
21:12:28.247684250 +0300
@@ -176,5 +176,6 @@
175 - Leadtek Winfast DTV1000S [107d:6655]
176 - Beholder BeholdTV 505 RDS[:5051]
177 - Hawell HW-404M7
-179 - Beholder BeholdTV H7[5ace:7190]
-180 - Beholder BeholdTV A7[5ace:7090]
+178 - Beholder BeholdTV H7[5ace:7190]
+179 - Beholder BeholdTV A7[5ace:7090]
+180 - Compro VideoMate M1F[185b:c900]
diff -uprN v4l-dvb_orig/drivers/media/IR/keymaps/Makefile
v4l-dvb/drivers/media/IR/keymaps/Makefile
--- v4l-dvb_orig/drivers/media/IR/keymaps/Makefile 2010-05-26
20:34:09.0 +0300
+++ v4l-dvb/drivers/media/IR/keymaps/Makefile 2010-05-26
21:09:41.498117258 +0300
@@ -61,6 +61,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t
rc-terratec-cinergy-xs.o \
rc-tevii-nec.o \
rc-tt-1500.o \
+ rc-videomate-m1f.o \
rc-videomate-s350.o \
rc-videomate-tv-pvr.o \
rc-winfast.o \
diff -uprN v4l-dvb_orig/drivers/media/IR/keymaps/rc-videomate-m1f.c
v4l-dvb/drivers/media/IR/keymaps/rc-videomate-m1f.c
--- v4l-dvb_orig/drivers/media/IR/keymaps/rc-videomate-m1f.c1970-01-01
03:00:00.0 +0300
+++ v4l-dvb/drivers/media/IR/keymaps/rc-videomate-m1f.c 2010-05-26
22:27:31.99335 +0300
@@ -0,0 +1,92 @@
+/* videomate-m1f.h - Keytable for videomate_m1f Remote Controller
+ *
+ * keymap imported from ir-keymaps.c
+ *
+ * Copyright (c) 2010 by Pavel Osnova pvosn...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include media/rc-map.h
+
+static struct ir_scancode videomate_m1f[] = {
+ { 0x01, KEY_POWER },
+ { 0x31, KEY_TUNER },
+ { 0x33, KEY_VIDEO },
+ { 0x2f, KEY_RADIO },
+ { 0x30, KEY_CAMERA
Re: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode
On Sunday 30 May 2010 21:26:14 Andy Walls wrote: On Sun, 2010-05-30 at 19:55 +0200, Ondrej Zary wrote: On Sunday 30 May 2010 13:34:55 Jean-Francois Moine wrote: On Sat, 29 May 2010 21:32:07 +0200 Ondrej Zary li...@rainbow-software.org wrote: The Color Space/Compression reported by the driver is only one: RGB 24 The driver also uses these files which may (or may not) be related to used compression: iyuv_32.dll, msh263.drv, msyuv.dll, tsbyuv.dll In standalone mode, the camera records video in MJPEG format. Hello Ondrej, Bad news, the images are compressed by an unknown algorithm (unknown from Linux point of vue). The decompression function could be found in some part of the ms-win driver, but: - first, I have no time to search and disassemble this function, - then, I did have this problem with an other webcam (17a1:0118), and after searching for a long time, nobody could find the function, and the driver is in stand-by since 2 years, - eventually, is this legal? That's bad... The driver contains file sp5x_32.dll which is registered in system.ini file as [drivers32] VIDC.SP54=SP5X_32.DLL Seems that the codec is called SP54 - hope that it's used to decompress the data. All I can do is to code the driver and let you or anyone find the decompression function... SP54 is Sunplus' ( http://www.sunplus.com.tw/ ) FourCC code for a version of MJPEG with the headers removed according to http://www.fourcc.org/ Maybe we can dump some data, create AVI file from that and try to decode the file using that codec. FourCC.org points to this page: http://libland.fr.st/download.html which points to a utility to conver the data back into an MJPEG: http://mxhaard.free.fr/spca50x/Download/sp54convert.tar.gz I have no idea if any of the above is true, 'cause I read it on the Internet. ;) Modified that utility to work on raw video frame extracted from usbsnoop file. The bad news is that the resulting jpeg file is not readable. I also deleted the sp5x_32.dll file and the camera still works... -- Ondrej Zary -- 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: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode
On Sun, 2010-05-30 at 23:28 +0200, Ondrej Zary wrote: On Sunday 30 May 2010 21:26:14 Andy Walls wrote: On Sun, 2010-05-30 at 19:55 +0200, Ondrej Zary wrote: On Sunday 30 May 2010 13:34:55 Jean-Francois Moine wrote: SP54 is Sunplus' ( http://www.sunplus.com.tw/ ) FourCC code for a version of MJPEG with the headers removed according to http://www.fourcc.org/ Maybe we can dump some data, create AVI file from that and try to decode the file using that codec. FourCC.org points to this page: http://libland.fr.st/download.html which points to a utility to conver the data back into an MJPEG: http://mxhaard.free.fr/spca50x/Download/sp54convert.tar.gz I have no idea if any of the above is true, 'cause I read it on the Internet. ;) Modified that utility to work on raw video frame extracted from usbsnoop file. The bad news is that the resulting jpeg file is not readable. I also deleted the sp5x_32.dll file and the camera still works... I would try extracting a JPEG header from one of the files captured by the camera in stand alone mode (either a JPEG still or MJPEG file), and put that header together with the image data from the USB capture. It may not look perfect, but hopefully you will get something you recognize. Attached was Theodore's first attempt of such a procedure with a header extracted from a standalone image file from my Jeilin based camera and USB snoop data from the same camera. It wasn't perfect, but it was recognizable. I did look at the image data file Jean-Francois provided from your usbsnoop logs. To my eye the data looks like it is Huffman coded (indicating JPEG). Maybe I'm just seeing what I want to see. Regards, Andy attachment: frame_one.jpg
Re: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode
On Sunday 30 May 2010 23:58:11 Andy Walls wrote: On Sun, 2010-05-30 at 23:28 +0200, Ondrej Zary wrote: On Sunday 30 May 2010 21:26:14 Andy Walls wrote: On Sun, 2010-05-30 at 19:55 +0200, Ondrej Zary wrote: On Sunday 30 May 2010 13:34:55 Jean-Francois Moine wrote: SP54 is Sunplus' ( http://www.sunplus.com.tw/ ) FourCC code for a version of MJPEG with the headers removed according to http://www.fourcc.org/ Maybe we can dump some data, create AVI file from that and try to decode the file using that codec. FourCC.org points to this page: http://libland.fr.st/download.html which points to a utility to conver the data back into an MJPEG: http://mxhaard.free.fr/spca50x/Download/sp54convert.tar.gz I have no idea if any of the above is true, 'cause I read it on the Internet. ;) Modified that utility to work on raw video frame extracted from usbsnoop file. The bad news is that the resulting jpeg file is not readable. I also deleted the sp5x_32.dll file and the camera still works... I would try extracting a JPEG header from one of the files captured by the camera in stand alone mode (either a JPEG still or MJPEG file), and put that header together with the image data from the USB capture. It may not look perfect, but hopefully you will get something you recognize. Just thought about the same thing so I uploaded a video file: http://www.rainbow-software.org/linux_files/spca1528/sunp0003.avi Attached was Theodore's first attempt of such a procedure with a header extracted from a standalone image file from my Jeilin based camera and USB snoop data from the same camera. It wasn't perfect, but it was recognizable. Thanks, I'll try that tomorrow. I did look at the image data file Jean-Francois provided from your usbsnoop logs. To my eye the data looks like it is Huffman coded (indicating JPEG). Maybe I'm just seeing what I want to see. Regards, Andy -- Ondrej Zary -- 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
[PATH 0/3] gspca-gl860 driver update
Hello Here is three patches for the gspca_gl860 driver. The main patch is the second one, it is a rewrite for the sensor MI2020. These patches have been proposed on February 28th and refused some days later because of a concern about the use of udelay instead of msleep. Compared to February, there is no more use of udelay. I also mapped a new setting to an already existing one in V4L2 instead of the new one. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] Gspca-gl860 driver update
gspca - gl860: minor fixes
From: Olivier Lorin o.lo...@laposte.net
- Change of rounded image resolutions to the real ones
- Fix for an irrelevant OV9655 image resolution identifier name
- Extra spaces to align some variable names and a defined value
Priority: normal
Signed-off-by: Olivier Lorin o.lo...@laposte.net
diff -rupN der_gl860b/gl860.c gl860/gl860.c
--- der_gl860b/gl860.c 2010-03-27 10:08:16.0 +0100
+++ gl860/gl860.c 2010-04-28 23:26:53.0 +0200
@@ -235,9 +235,9 @@ static struct v4l2_pix_format mi2020_mod
.colorspace = V4L2_COLORSPACE_SRGB,
.priv = 0
},
- { 800, 600, V4L2_PIX_FMT_SGBRG8, V4L2_FIELD_NONE,
+ { 800, 598, V4L2_PIX_FMT_SGBRG8, V4L2_FIELD_NONE,
.bytesperline = 800,
- .sizeimage = 800 * 600,
+ .sizeimage = 800 * 598,
.colorspace = V4L2_COLORSPACE_SRGB,
.priv = 1
},
@@ -247,9 +247,9 @@ static struct v4l2_pix_format mi2020_mod
.colorspace = V4L2_COLORSPACE_SRGB,
.priv = 2
},
- {1600, 1200, V4L2_PIX_FMT_SGBRG8, V4L2_FIELD_NONE,
+ {1600, 1198, V4L2_PIX_FMT_SGBRG8, V4L2_FIELD_NONE,
.bytesperline = 1600,
- .sizeimage = 1600 * 1200,
+ .sizeimage = 1600 * 1198,
.colorspace = V4L2_COLORSPACE_SRGB,
.priv = 3
},
diff -rupN der_gl860b/gl860.h gl860/gl860.h
--- der_gl860b/gl860.h 2010-03-27 10:08:25.0 +0100
+++ gl860/gl860.h 2010-04-28 13:56:51.0 +0200
@@ -44,7 +44,7 @@
#define IMAGE_640 0
#define IMAGE_800 1
#define IMAGE_1280 2
-#define IMAGE_1600 3
+#define IMAGE_1600 3
struct sd_gl860 {
u16 backlight;
@@ -75,10 +75,10 @@ struct sd {
int (*dev_camera_settings)(struct gspca_dev *);
u8 swapRB;
- u8 mirrorMask;
- u8 sensor;
- s32 nbIm;
- s32 nbRightUp;
+ u8 mirrorMask;
+ u8 sensor;
+ s32 nbIm;
+ s32 nbRightUp;
u8 waitSet;
};
diff -rupN der_gl860b/gl860-ov9655.c gl860/gl860-ov9655.c
--- der_gl860b/gl860-ov9655.c 2010-03-27 10:08:16.0 +0100
+++ gl860/gl860-ov9655.c2010-04-28 13:39:14.0 +0200
@@ -69,7 +69,7 @@ static u8 *tbl_640[] = {
\xd0\x01\xd1\x08\xd2\xe0\xd3\x01 \xd4\x10\xd5\x80
};
-static u8 *tbl_800[] = {
+static u8 *tbl_1280[] = {
\x00\x40\x07\x6a\x06\xf3\x0d\x6a \x10\x10\xc1\x01
,
\x12\x80\x00\x00\x01\x98\x02\x80 \x03\x12\x04\x01\x0b\x57\x0e\x61
@@ -217,7 +217,7 @@ static int ov9655_init_post_alt(struct g
ctrl_out(gspca_dev, 0x40, 5, 0x0001, 0x, 0, NULL);
- tbl = (reso == IMAGE_640) ? tbl_640 : tbl_800;
+ tbl = (reso == IMAGE_640) ? tbl_640 : tbl_1280;
ctrl_out(gspca_dev, 0x40, 3, 0x, 0x0200,
tbl_length[0], tbl[0]);
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] Gspca-gl860 - MI2030 sensor subdriver rewrite
gspca - gl860: new driver for MI2020 sensor
From: Olivier Lorin o.lo...@laposte.net
- new MI2020 driver version made from a webcam given to me
- remove all previous flavors of this driver
Priority: normal
Signed-off-by: Olivier Lorin o.lo...@laposte.net
diff -urpN der_gl860i1/gl860.c gl860/gl860.c
--- der_gl860i1/gl860.c 2010-04-28 23:26:53.0 +0200
+++ gl860/gl860.c 2010-04-29 21:01:15.0 +0200
@@ -91,7 +91,6 @@ SD_SETGET(contrast)
/* control table */
static struct ctrl sd_ctrls_mi1320[GL860_NCTRLS];
static struct ctrl sd_ctrls_mi2020[GL860_NCTRLS];
-static struct ctrl sd_ctrls_mi2020b[GL860_NCTRLS];
static struct ctrl sd_ctrls_ov2640[GL860_NCTRLS];
static struct ctrl sd_ctrls_ov9655[GL860_NCTRLS];
@@ -121,8 +120,6 @@ static int gl860_build_control_table(str
sd_ctrls = sd_ctrls_mi1320;
else if (_MI2020_)
sd_ctrls = sd_ctrls_mi2020;
- else if (_MI2020b_)
- sd_ctrls = sd_ctrls_mi2020b;
else if (_OV2640_)
sd_ctrls = sd_ctrls_ov2640;
else if (_OV9655_)
@@ -187,19 +184,6 @@ static const struct sd_desc sd_desc_mi20
.dq_callback = sd_callback,
};
-static const struct sd_desc sd_desc_mi2020b = {
- .name= MODULE_NAME,
- .ctrls = sd_ctrls_mi2020b,
- .nctrls = GL860_NCTRLS,
- .config = sd_config,
- .init= sd_init,
- .isoc_init = sd_isoc_init,
- .start = sd_start,
- .stop0 = sd_stop0,
- .pkt_scan= sd_pkt_scan,
- .dq_callback = sd_callback,
-};
-
static const struct sd_desc sd_desc_ov2640 = {
.name= MODULE_NAME,
.ctrls = sd_ctrls_ov2640,
@@ -344,8 +328,6 @@ static int sd_config(struct gspca_dev *g
sd-sensor = ID_OV9655;
else if (strcmp(sensor, MI2020) == 0)
sd-sensor = ID_MI2020;
- else if (strcmp(sensor, MI2020b) == 0)
- sd-sensor = ID_MI2020b;
/* Get sensor and set the suitable init/start/../stop functions */
if (gl860_guess_sensor(gspca_dev, vendor_id, product_id) == -1)
@@ -369,13 +351,6 @@ static int sd_config(struct gspca_dev *g
dev_init_settings = mi2020_init_settings;
break;
- case ID_MI2020b:
- gspca_dev-sd_desc = sd_desc_mi2020b;
- cam-cam_mode = mi2020_mode;
- cam-nmodes = ARRAY_SIZE(mi2020_mode);
- dev_init_settings = mi2020_init_settings;
- break;
-
case ID_OV2640:
gspca_dev-sd_desc = sd_desc_ov2640;
cam-cam_mode = ov2640_mode;
@@ -620,7 +595,7 @@ int gl860_RTx(struct gspca_dev *gspca_de
else if (len 1 r len)
PDEBUG(D_ERR, short ctrl transfer %d/%d, r, len);
- if ((_MI2020_ || _MI2020b_ || _MI2020c_) (val || index))
+ if (_MI2020_ (val || index))
msleep(1);
if (_OV2640_)
msleep(1);
@@ -767,8 +742,6 @@ static int gl860_guess_sensor(struct gsp
PDEBUG(D_PROBE, 05e3:f191 sensor MI1320 (1.3M));
} else if (_MI2020_) {
PDEBUG(D_PROBE, 05e3:0503 sensor MI2020 (2.0M));
- } else if (_MI2020b_) {
- PDEBUG(D_PROBE, 05e3:0503 sensor MI2020 alt. driver (2.0M));
} else if (_OV9655_) {
PDEBUG(D_PROBE, 05e3:0503 sensor OV9655 (1.3M));
} else if (_OV2640_) {
diff -urpN der_gl860i1/gl860.h gl860/gl860.h
--- der_gl860i1/gl860.h 2010-04-28 13:56:51.0 +0200
+++ gl860/gl860.h 2010-04-28 13:36:36.0 +0200
@@ -32,12 +32,9 @@
#define ID_OV2640 2
#define ID_OV9655 4
#define ID_MI2020 8
-#define ID_MI2020b 16
#define _MI1320_ (((struct sd *) gspca_dev)-sensor == ID_MI1320)
#define _MI2020_ (((struct sd *) gspca_dev)-sensor == ID_MI2020)
-#define _MI2020b_ (((struct sd *) gspca_dev)-sensor == ID_MI2020b)
-#define _MI2020c_ 0
#define _OV2640_ (((struct sd *) gspca_dev)-sensor == ID_OV2640)
#define _OV9655_ (((struct sd *) gspca_dev)-sensor == ID_OV9655)
diff -urpN der_gl860i1/gl860-mi2020.c gl860/gl860-mi2020.c
--- der_gl860i1/gl860-mi2020.c 2009-12-30 18:19:11.0 +0100
+++ gl860/gl860-mi2020.c2010-05-30 23:41:56.0 +0200
@@ -1,6 +1,7 @@
/* Subdriver for the GL860 chip with the MI2020 sensor
- * Author Olivier LORIN, from Ice/Soro2005's logs(A), Fret_saw/Hulkie's
- * logs(B) and Tricids logs(C). With the help of
Kytrix/BUGabundo/Blazercist.
+ * Author Olivier LORIN, from logs by Iceman/Soro2005 +
Fret_saw/Hulkie/Tricid
+ * with the help of Kytrix/BUGabundo/Blazercist.
+ * Driver achieved thanks to a webcam gift by Kytrix.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -20,47 +21,70 @@
#include gl860.h
+static u8 dat_wbal1[] = {0x8c, 0xa2, 0x0c};
+
static u8 dat_bright1[] = {0x8c, 0xa2,
[PATCH 3/3] Gspca-gl860 driver update
gspca - gl860: minor functional changes From: Olivier Lorin o.lo...@laposte.net - Setting changes applied after an end of image marker reception This is the way MI2020 sensor works. It seems to be logical to wait for a complete image before to change a setting. - 1 ms msleep applied to each sensor after USB control data exchange This was done for two sensors because these exchanges were known to be too quick depending on laptop model. It should be fairly logical to apply this delay to each sensor in order to prevent from having errors with untested hardwares. Priority: normal Signed-off-by: Olivier Lorin o.lo...@laposte.net diff -urpN der_gl860i3/gl860.c gl860/gl860.c --- der_gl860i3/gl860.c 2010-04-29 21:01:15.0 +0200 +++ gl860/gl860.c 2010-04-28 23:45:19.0 +0200 @@ -63,7 +63,7 @@ static int sd_set_##thename(struct gspca \ sd-vcur.thename = val;\ if (gspca_dev-streaming)\ - sd-dev_camera_settings(gspca_dev);\ + sd-waitSet = 1;\ return 0;\ } \ static int sd_get_##thename(struct gspca_dev *gspca_dev, s32 *val)\ @@ -595,10 +595,7 @@ int gl860_RTx(struct gspca_dev *gspca_de else if (len 1 r len) PDEBUG(D_ERR, short ctrl transfer %d/%d, r, len); - if (_MI2020_ (val || index)) - msleep(1); - if (_OV2640_) - msleep(1); + msleep(1); return r; } -- 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: mt9m111 swap_rgb_red_blue
Sascha Hauer s.ha...@pengutronix.de writes: Hi Robert, I have digged around in the Datasheet and if I understand it correctly the PXA swaps red/blue in RGB mode. So if we do not use rgb mode but yuv (which should be a pass through) we should be able to support rgb on PXA aswell. Robert, can you confirm that with the following patch applied you still get an image but with red/blue swapped? I can confirm the color swap. If you want to follow that path, I would suggest instead : cicr1 |= CICR1_COLOR_SP_VAL(0); There is no difference from a processing point of view, it's just that CICR1_COLOR_SP_VAL(0) is raw colorspace, with means pass through, and that seems to be your goal here. Note that the patch would have to be completed with the BGR565 into RGB565 conversion, if the sensor was to provide only BGR565. But that could very well be for another patch. Cheers. -- Robert -- 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] Compro Videomate T750F Vista digital+analog support
HI!
I have downloaded latest hg v4l and adapted the compro
t750f support patch. The patch is the same but v4l code is
newer so there's some improvement
Restarting VDR is now stable. Tried it cca 10x VDR restarts,
DVB-T tuner always worked. Remote still has 10% keys lost.
ALSA device now appears with alsa=1 in the list
arecord -l (but I haven't tried to capture anything yet)
Someone mentioned that MCE-alike remote is the same to all
f-series of the cards so I called it rc-videomate-f.
Here's the patch
diff -r 304cfde05b3f linux/drivers/media/IR/keymaps/Makefile
--- a/linux/drivers/media/IR/keymaps/Makefile Tue May 25 23:50:51 2010 -0400
+++ b/linux/drivers/media/IR/keymaps/Makefile Mon May 31 01:18:12 2010 +0200
@@ -63,5 +63,6 @@
rc-tt-1500.o \
rc-videomate-s350.o \
rc-videomate-tv-pvr.o \
+ rc-videomate-f.o \
rc-winfast.o \
rc-winfast-usbii-deluxe.o
diff -r 304cfde05b3f linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Tue May 25 23:50:51
2010 -0400
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Mon May 31 01:18:12
2010 +0200
@@ -4920,12 +4920,14 @@
},
[SAA7134_BOARD_VIDEOMATE_T750] = {
/* John Newbigin j...@it.swin.edu.au */
+ /* Emard 2010-05-10 v18-v4l davorem...@gmail.com */
.name = Compro VideoMate T750,
.audio_clock= 0x00187de7,
.tuner_type = TUNER_XC2028,
.radio_type = UNSET,
- .tuner_addr = ADDR_UNSET,
+ .tuner_addr = 0x61,
.radio_addr = ADDR_UNSET,
+ .mpeg = SAA7134_MPEG_DVB,
.inputs = {{
.name = name_tv,
.vmux = 3,
@@ -6752,6 +6754,11 @@
msleep(10);
saa7134_set_gpio(dev, 18, 1);
break;
+ case SAA7134_BOARD_VIDEOMATE_T750:
+ saa7134_set_gpio(dev, 20, 0);
+ msleep(10);
+ saa7134_set_gpio(dev, 20, 1);
+ break;
}
return 0;
}
@@ -7171,6 +7178,11 @@
saa_andorl(SAA7134_GPIO_GPMODE0 2, 0xC000, 0xC000);
saa_andorl(SAA7134_GPIO_GPSTATUS0 2, 0xC000, 0xC000);
break;
+ case SAA7134_BOARD_VIDEOMATE_T750:
+ dev-has_remote = SAA7134_REMOTE_GPIO;
+ saa_andorl(SAA7134_GPIO_GPMODE0 2, 0x8000, 0x8000);
+ saa_andorl(SAA7134_GPIO_GPSTATUS0 2, 0x8000, 0x8000);
+ break;
}
return 0;
}
diff -r 304cfde05b3f linux/drivers/media/video/saa7134/saa7134-dvb.c
--- a/linux/drivers/media/video/saa7134/saa7134-dvb.c Tue May 25 23:50:51
2010 -0400
+++ b/linux/drivers/media/video/saa7134/saa7134-dvb.c Mon May 31 01:18:12
2010 +0200
@@ -55,6 +55,7 @@
#include tda8290.h
#include zl10353.h
+#include qt1010.h
#include zl10036.h
#include zl10039.h
@@ -886,6 +887,17 @@
.disable_i2c_gate_ctrl = 1,
};
+static struct zl10353_config videomate_t750_zl10353_config = {
+ .demod_address = 0x0f,
+ .no_tuner = 1,
+ .parallel_ts = 1,
+};
+
+static struct qt1010_config videomate_t750_qt1010_config = {
+ .i2c_address = 0x62
+};
+
+
/* ==
* tda10086 based DVB-S cards, helper functions
*/
@@ -1569,6 +1581,21 @@
__func__);
break;
+ case SAA7134_BOARD_VIDEOMATE_T750:
+ printk(Compro VideoMate T750 DVB setup\n);
+ fe0-dvb.frontend = dvb_attach(zl10353_attach,
+ videomate_t750_zl10353_config,
+ dev-i2c_adap);
+ if (fe0-dvb.frontend != NULL) {
+ // if there is a gate function then the i2c bus
breaks.!
+ fe0-dvb.frontend-ops.i2c_gate_ctrl = 0;
+ if (dvb_attach(qt1010_attach,
+ fe0-dvb.frontend,
+ dev-i2c_adap,
+ videomate_t750_qt1010_config) == NULL)
+ wprintk(error attaching QT1010\n);
+ }
+ break;
case SAA7134_BOARD_ZOLID_HYBRID_PCI:
fe0-dvb.frontend = dvb_attach(tda10048_attach,
zolid_tda10048_config,
diff -r 304cfde05b3f linux/drivers/media/video/saa7134/saa7134-input.c
--- a/linux/drivers/media/video/saa7134/saa7134-input.c Tue May 25 23:50:51
2010 -0400
+++
Re: [PATCH] Compro Videomate T750F Vista digital+analog support
Hi Davor,
Am Montag, den 31.05.2010, 01:48 +0200 schrieb Davor Emard:
HI!
I have downloaded latest hg v4l and adapted the compro
t750f support patch. The patch is the same but v4l code is
newer so there's some improvement
Restarting VDR is now stable. Tried it cca 10x VDR restarts,
DVB-T tuner always worked. Remote still has 10% keys lost.
ALSA device now appears with alsa=1 in the list
arecord -l (but I haven't tried to capture anything yet)
Someone mentioned that MCE-alike remote is the same to all
f-series of the cards so I called it rc-videomate-f.
Here's the patch
likely one of the most difficult cards on that driver during the last
time.
Does't look such bad to me, after all, without having one.
Hmm, somehow its #define in the saa7134.h header is missing?
I'm also wondering, why we don't see the usual three lines offset on the
end of current patches.
Cheers,
Hermann
diff -r 304cfde05b3f linux/drivers/media/IR/keymaps/Makefile
--- a/linux/drivers/media/IR/keymaps/Makefile Tue May 25 23:50:51 2010 -0400
+++ b/linux/drivers/media/IR/keymaps/Makefile Mon May 31 01:18:12 2010 +0200
@@ -63,5 +63,6 @@
rc-tt-1500.o \
rc-videomate-s350.o \
rc-videomate-tv-pvr.o \
+ rc-videomate-f.o \
rc-winfast.o \
rc-winfast-usbii-deluxe.o
diff -r 304cfde05b3f linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Tue May 25
23:50:51 2010 -0400
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Mon May 31
01:18:12 2010 +0200
@@ -4920,12 +4920,14 @@
},
[SAA7134_BOARD_VIDEOMATE_T750] = {
/* John Newbigin j...@it.swin.edu.au */
+ /* Emard 2010-05-10 v18-v4l davorem...@gmail.com */
.name = Compro VideoMate T750,
.audio_clock= 0x00187de7,
.tuner_type = TUNER_XC2028,
.radio_type = UNSET,
- .tuner_addr = ADDR_UNSET,
+ .tuner_addr = 0x61,
.radio_addr = ADDR_UNSET,
+ .mpeg = SAA7134_MPEG_DVB,
.inputs = {{
.name = name_tv,
.vmux = 3,
@@ -6752,6 +6754,11 @@
msleep(10);
saa7134_set_gpio(dev, 18, 1);
break;
+ case SAA7134_BOARD_VIDEOMATE_T750:
+ saa7134_set_gpio(dev, 20, 0);
+ msleep(10);
+ saa7134_set_gpio(dev, 20, 1);
+ break;
}
return 0;
}
@@ -7171,6 +7178,11 @@
saa_andorl(SAA7134_GPIO_GPMODE0 2, 0xC000, 0xC000);
saa_andorl(SAA7134_GPIO_GPSTATUS0 2, 0xC000, 0xC000);
break;
+ case SAA7134_BOARD_VIDEOMATE_T750:
+ dev-has_remote = SAA7134_REMOTE_GPIO;
+ saa_andorl(SAA7134_GPIO_GPMODE0 2, 0x8000, 0x8000);
+ saa_andorl(SAA7134_GPIO_GPSTATUS0 2, 0x8000, 0x8000);
+ break;
}
return 0;
}
diff -r 304cfde05b3f linux/drivers/media/video/saa7134/saa7134-dvb.c
--- a/linux/drivers/media/video/saa7134/saa7134-dvb.c Tue May 25 23:50:51
2010 -0400
+++ b/linux/drivers/media/video/saa7134/saa7134-dvb.c Mon May 31 01:18:12
2010 +0200
@@ -55,6 +55,7 @@
#include tda8290.h
#include zl10353.h
+#include qt1010.h
#include zl10036.h
#include zl10039.h
@@ -886,6 +887,17 @@
.disable_i2c_gate_ctrl = 1,
};
+static struct zl10353_config videomate_t750_zl10353_config = {
+ .demod_address = 0x0f,
+ .no_tuner = 1,
+ .parallel_ts = 1,
+};
+
+static struct qt1010_config videomate_t750_qt1010_config = {
+ .i2c_address = 0x62
+};
+
+
/* ==
* tda10086 based DVB-S cards, helper functions
*/
@@ -1569,6 +1581,21 @@
__func__);
break;
+ case SAA7134_BOARD_VIDEOMATE_T750:
+ printk(Compro VideoMate T750 DVB setup\n);
+ fe0-dvb.frontend = dvb_attach(zl10353_attach,
+ videomate_t750_zl10353_config,
+ dev-i2c_adap);
+ if (fe0-dvb.frontend != NULL) {
+ // if there is a gate function then the i2c bus
breaks.!
+ fe0-dvb.frontend-ops.i2c_gate_ctrl = 0;
+ if (dvb_attach(qt1010_attach,
+ fe0-dvb.frontend,
+ dev-i2c_adap,
+ videomate_t750_qt1010_config) == NULL)
+ wprintk(error attaching QT1010\n);
+ }
+
Re: [PATCH] Compro Videomate T750F Vista digital+analog support
Hmm, somehow its #define in the saa7134.h header is missing? I'm also wondering, why we don't see the usual three lines offset on the end of current patches. Forget about the later, is in new file mode. 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: [PATCH] Compro Videomate T750F Vista digital+analog support
HI Forget about the later, is in new file mode. I wanted the new file but I don't know hg diff too much so I just manually cat to append to the hg diff output... d. -- 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] Compro Videomate T750F Vista digital+analog support
HI! Can you also try this GPIO settings? It's my try to use last summer's registers dump to setup gpio mask and value case SAA7134_BOARD_VIDEOMATE_T750: dev-has_remote = SAA7134_REMOTE_GPIO; saa_andorl(SAA7134_GPIO_GPMODE0 2, 0x8082c000, 0x8082c000); saa_andorl(SAA7134_GPIO_GPSTATUS0 2, 0x8082c000, 0x0080c000); break; -- 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: TBS 6980 Dual Tuner PCI-e card.....not in Wiki at all?
Konstantin Dimitrov a écrit : hello, i can't comment on your questions about the Wiki, but i made the driver for TBS 6980 and i can ensure you that the driver will be released as open-source under GPL as soon as i have permission to do that, but compared to other cards at least even at the moment you can use the card in Linux and it's very easy to add support for it using the binary modules even to the latest V4L code from repository and so those blobs are actually not so big limitation. also, you are very wrong about the price - as far as i know retails price is less than 200 USD, for example TBS online shop gives a price of 158.99 USD: http://www.buydvb.net/pcie-dvbs2-dual-tuner-tv-card_p11.html and i believe the dual DVB-S2 card with price of 1000 USD that you're talking about is the NetUP one and not the TurboSight TBS 6980 dual DVB-S2 card. I have two questions for you: do these board support (or will support in the near future) a CI interface for pay TV, and what is the best symbol rate they can achieve in DVB-S2 (I think I need QPSK only but could be 8PSK) RELIABLY. TIA Bye Manu -- 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: TBS 6980 Dual Tuner PCI-e card.....not in Wiki at all?
On Mon, May 31, 2010 at 5:05 AM, Emmanuel eall...@gmail.com wrote: Konstantin Dimitrov a écrit : hello, i can't comment on your questions about the Wiki, but i made the driver for TBS 6980 and i can ensure you that the driver will be released as open-source under GPL as soon as i have permission to do that, but compared to other cards at least even at the moment you can use the card in Linux and it's very easy to add support for it using the binary modules even to the latest V4L code from repository and so those blobs are actually not so big limitation. also, you are very wrong about the price - as far as i know retails price is less than 200 USD, for example TBS online shop gives a price of 158.99 USD: http://www.buydvb.net/pcie-dvbs2-dual-tuner-tv-card_p11.html and i believe the dual DVB-S2 card with price of 1000 USD that you're talking about is the NetUP one and not the TurboSight TBS 6980 dual DVB-S2 card. I have two questions for you: do these board support (or will support in the near future) a CI interface for pay TV, and what is the best symbol rate they can achieve in DVB-S2 (I think I need QPSK only but could be 8PSK) TBS 6980 specifications are: DVB-S QPKS: 1000 - 45000 kSps DVB-S2 QPSK and 8PSK: 2000 - 36000 kSps but i personally have tested DVB-S2 8PSK up to 33500 kSps and it works fine. so, DVB-S2 symbol rate range is still better than what most other cards can offer i believe, which usually support 1 - 3 kSps for DVB-S2. TBS are developing card that will support 1000 - 45000 kSps for DVB-S2 (both QPSK and 8PSK), but i believe it won't be released any time soon. RELIABLY. TIA Bye Manu -- 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: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode
On Sun, 2010-05-30 at 20:13 +0200, Jean-Francois Moine wrote:
On Sun, 30 May 2010 19:55:22 +0200
Ondrej Zary li...@rainbow-software.org wrote:
That's bad...
The driver contains file sp5x_32.dll which is registered in
system.ini file as [drivers32]
VIDC.SP54=SP5X_32.DLL
Seems that the codec is called SP54 - hope that it's used to
decompress the data.
All I can do is to code the driver and let you or anyone find the
decompression function...
Maybe we can dump some data, create AVI file from that and try to
decode the file using that codec.
It is easy to get images from the usbsnoop files. I join an image
extracted from your file usbsnoop-video-capture-640x480.log. If you
want more images, they are in IsoPackets. The first 2 bytes of each isoc
packet mean:
- '02 80' or '02 81': first of intermediate part of the image ('0' or
'1' is the image sequence number)
- '02 82' or '02 83': last part of the image
Someone had an idea to try and guess the compression algorithm: do
usbsnoop's with full black and full white images. But this idea did not
work with the other webcam: the images were quite the same!
I have attached an image I constructed from the image data file you
provided, the MJPEG headers in the AVI file Ondrej provided, and the
Huffman table in the jpeg.h file in the gspca driver.
If you zoom in, there is an small pattern in the top left portion of the
scan.
I doesn't look quite like an whole image, but it does look like the
start of one.
Regards,
Andy
attachment: test1.jpg000: ff d8 ff e0 00 10 4a 46 49 46 00 01 01 00 00 01 ..JFIF..
010: 00 01 00 00 ff db 00 c5 00 0a 07 07 08 07 06 0a
020: 08 08 08 0b 0a 0a 0b 0e 18 10 0e 0d 0d 0e 1d 15
030: 16 11 18 23 1f 25 24 22 1f 22 21 26 2b 37 2f 26 ...#.%$.!+7/
040: 29 34 29 21 22 30 41 31 34 39 3b 3e 3e 3e 25 2e )4)!0A149;%.
050: 44 49 43 3c 48 37 3d 3e 3b 01 0a 0b 0b 0e 0d 0e DICH7=;...
060: 1c 10 10 1c 3b 28 22 28 3b 3b 3b 3b 3b 3b 3b 3b ;((
070: 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b
080: 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b
090: 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 02 17 18 18 24 21 ;;$!
0a0: 24 47 26 26 47 99 66 56 66 99 99 99 99 99 99 99 $GG.fVf...
0b0: 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99
0c0: 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99
0d0: 99 99 99 99 99 99 99 99 99 99 99 ff c4 01 a2 00
0e0: 00 01 05 01 01 01 01 01 01 00 00 00 00 00 00 00
0f0: 00 01 02 03 04 05 06 07 08 09 0a 0b 01 00 03 01
100: 01 01 01 01 01 01 01 01 00 00 00 00 00 00 01 02
110: 03 04 05 06 07 08 09 0a 0b 10 00 02 01 03 03 02
120: 04 03 05 05 04 04 00 00 01 7d 01 02 03 00 04 11 .}..
130: 05 12 21 31 41 06 13 51 61 07 22 71 14 32 81 91 ..!1A..Qa.q.2..
140: a1 08 23 42 b1 c1 15 52 d1 f0 24 33 62 72 82 09 ..#B...R..$3br..
150: 0a 16 17 18 19 1a 25 26 27 28 29 2a 34 35 36 37 ..%'()*4567
160: 38 39 3a 43 44 45 46 47 48 49 4a 53 54 55 56 57 89:CDEFGHIJSTUVW
170: 58 59 5a 63 64 65 66 67 68 69 6a 73 74 75 76 77 XYZcdefghijstuvw
180: 78 79 7a 83 84 85 86 87 88 89 8a 92 93 94 95 96 xyz.
190: 97 98 99 9a a2 a3 a4 a5 a6 a7 a8 a9 aa b2 b3 b4
1a0: b5 b6 b7 b8 b9 ba c2 c3 c4 c5 c6 c7 c8 c9 ca d2
1b0: d3 d4 d5 d6 d7 d8 d9 da e1 e2 e3 e4 e5 e6 e7 e8
1c0: e9 ea f1 f2 f3 f4 f5 f6 f7 f8 f9 fa 11 00 02 01
1d0: 02 04 04 03 04 07 05 04 04 00 01 02 77 00 01 02 w...
1e0: 03 11 04 05 21 31 06 12 41 51 07 61 71 13 22 32 !1..AQ.aq.2
1f0: 81 08 14 42 91 a1 b1 c1 09 23 33 52 f0 15 62 72 ...B.#3R..br
200: d1 0a 16 24 34 e1 25 f1 17 18 19 1a 26 27 28 29 ...$4.%.'()
210: 2a 35 36 37 38 39 3a 43 44 45 46 47 48 49 4a 53 *56789:CDEFGHIJS
220: 54 55 56 57 58 59 5a 63 64 65 66 67 68 69 6a 73 TUVWXYZcdefghijs
230: 74 75 76 77 78 79 7a 82 83 84 85 86 87 88 89 8a tuvwxyz.
240: 92 93 94 95 96 97 98 99 9a a2 a3 a4 a5 a6 a7 a8
250: a9 aa b2 b3 b4 b5 b6 b7 b8 b9 ba c2 c3 c4 c5 c6
260: c7 c8 c9 ca d2 d3 d4 d5 d6 d7 d8 d9 da e2 e3 e4
270: e5 e6 e7 e8 e9 ea f2 f3 f4 f5 f6 f7 f8 f9 fa ff
280: c0 00 11 08 01 e0 02 80 03 01 21 00 02 11 01 03 ..!.
290: 11 01 ff da 00 0c 03 01 00 02 11 03 11 00 3f 00 ..?.
Re: What ever happened to standardizing signal level?
Markus Rechberger wrote: On Sun, May 30, 2010 at 5:21 PM, Michael Krufky mkru...@linuxtv.org wrote: Markus Rechberger wrote: Hi, A little bit more ontopic, did anyone get around to read the signallevel of the tda18721? I wonder the register does not return any signallevel as indicated in the specifications. Markus There is a power level value that can be read from the tda18271 -- I had a patch that enabled reading of this value, for testing purposes, but it wasn't as useful as I had hoped, so I never bothered to merge it. If you'd like to play with it, I pushed up some code last year: http://kernellabs.com/hg/~mkrufky/tda18271-pl/rev/4373874cff29 Let me know how this works for you, or if you choose to change it. I If you find it valuable, we can merge it in somehow. hmm.. I somewhat tried the same but the register kept flipping back and the powerlevel register returned 0. Markus ...I think it only works on the c2 rev silicon. Not sure about that, though. -Mike -- 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: TBS 6980 Dual Tuner PCI-e card.....not in Wiki at all?
Konstantin Dimitrov a écrit : On Mon, May 31, 2010 at 5:05 AM, Emmanuel eall...@gmail.com mailto:eall...@gmail.com wrote: Konstantin Dimitrov a écrit : hello, i can't comment on your questions about the Wiki, but i made the driver for TBS 6980 and i can ensure you that the driver will be released as open-source under GPL as soon as i have permission to do that, but compared to other cards at least even at the moment you can use the card in Linux and it's very easy to add support for it using the binary modules even to the latest V4L code from repository and so those blobs are actually not so big limitation. also, you are very wrong about the price - as far as i know retails price is less than 200 USD, for example TBS online shop gives a price of 158.99 USD: http://www.buydvb.net/pcie-dvbs2-dual-tuner-tv-card_p11.html and i believe the dual DVB-S2 card with price of 1000 USD that you're talking about is the NetUP one and not the TurboSight TBS 6980 dual DVB-S2 card. I have two questions for you: do these board support (or will support in the near future) a CI interface for pay TV, and what is the best symbol rate they can achieve in DVB-S2 (I think I need QPSK only but could be 8PSK) RELIABLY. TBS 6980 specifications are: DVB-S QPKS: 1000 - 45000 kSps DVB-S2 QPSK and 8PSK: 2000 - 36000 kSps but i personally have tested DVB-S2 8PSK up to 33500 kSps and it works fine. so, DVB-S2 symbol rate range is still better than what most other cards can offer i believe, which usually support 1 - 3 kSps for DVB-S2. TBS are developing card that will support 1000 - 45000 kSps for DVB-S2 (both QPSK and 8PSK), but i believe it won't be released any time soon. OK Thansks. I am interested in a DVB-S2 card able to tune to 45000kSps rate with CI support (yes my provider here did things so that it is hard to get rid of their STB :( ) The only one for now are the cards based upon stv0900 like the mystique satix, but I am not sure about the driver supporting CI. Bye Manu -- 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: What ever happened to standardizing signal level?
Hi, Am Sonntag, den 30.05.2010, 23:02 -0400 schrieb Michael Krufky: Markus Rechberger wrote: On Sun, May 30, 2010 at 5:21 PM, Michael Krufky mkru...@linuxtv.org wrote: Markus Rechberger wrote: Hi, A little bit more ontopic, did anyone get around to read the signallevel of the tda18721? I wonder the register does not return any signallevel as indicated in the specifications. Markus There is a power level value that can be read from the tda18271 -- I had a patch that enabled reading of this value, for testing purposes, but it wasn't as useful as I had hoped, so I never bothered to merge it. If you'd like to play with it, I pushed up some code last year: http://kernellabs.com/hg/~mkrufky/tda18271-pl/rev/4373874cff29 Let me know how this works for you, or if you choose to change it. I If you find it valuable, we can merge it in somehow. hmm.. I somewhat tried the same but the register kept flipping back and the powerlevel register returned 0. Markus ...I think it only works on the c2 rev silicon. Not sure about that, though. -Mike that is such stuff that really happens and nobody has any intentions to hide better signal/SNR measurements from the users. Some multiple subscribed trolls may take it for a next round, but it is _nowhere_ any better. Even worse, on S2, the whole previous model of doing so, will come under pressure, if I'm not totally blind. Best, 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: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode
On Sun, 30 May 2010, Andy Walls wrote:
On Sun, 2010-05-30 at 20:13 +0200, Jean-Francois Moine wrote:
On Sun, 30 May 2010 19:55:22 +0200
Ondrej Zary li...@rainbow-software.org wrote:
That's bad...
The driver contains file sp5x_32.dll which is registered in
system.ini file as [drivers32]
VIDC.SP54=SP5X_32.DLL
Seems that the codec is called SP54 - hope that it's used to
decompress the data.
All I can do is to code the driver and let you or anyone find the
decompression function...
Maybe we can dump some data, create AVI file from that and try to
decode the file using that codec.
It is easy to get images from the usbsnoop files. I join an image
extracted from your file usbsnoop-video-capture-640x480.log. If you
want more images, they are in IsoPackets. The first 2 bytes of each isoc
packet mean:
- '02 80' or '02 81': first of intermediate part of the image ('0' or
'1' is the image sequence number)
- '02 82' or '02 83': last part of the image
Someone had an idea to try and guess the compression algorithm: do
usbsnoop's with full black and full white images. But this idea did not
work with the other webcam: the images were quite the same!
I have attached an image I constructed from the image data file you
provided, the MJPEG headers in the AVI file Ondrej provided, and the
Huffman table in the jpeg.h file in the gspca driver.
If you zoom in, there is an small pattern in the top left portion of the
scan.
I doesn't look quite like an whole image, but it does look like the
start of one.
Regards,
Andy
Downloaded it. And, hmmm. Here are the error messages on trying to look at
the output:
kilg...@khayyam:~$ display test1.jpg
display: Corrupt JPEG data: premature end of data segment `test1.jpg' @
warning/jpeg.c/EmitMessage/228.
display: Unsupported marker type 0x3a `test1.jpg' @
error/jpeg.c/EmitMessage/233.
kilg...@khayyam:~$
Quite possibly it _is_ going down strips or such. That is what the
JL2005C cameras are doing. Each vertical strip of 16 bytes from the
picture is in fact a separate JPEG image, and needs to be separately
processed, and then the results glued together into an image. This is even
seen in the raw data, once one is so wise that it is all figured out. The
data for each strip ends with FF D9. So one suggestion here would be to
see how many times the FF D9 is coming up in the data. There may be a
pattern to that.
Theodore Kilgore
--
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
2.6.35-rc1 fails to boot: OOPS in ir_register_class
Trying to boot the new -rc1 it fails with the following OOPS: [3.454804] IR NEC protocol handler initialized [3.461310] IR RC5(x) protocol handler initialized [3.467865] IR RC6 protocol handler initialized [3.474070] IR JVC protocol handler initialized [3.480257] IR Sony protocol handler initialized [3.480259] Linux video capture interface: v2.00 [3.480722] bttv: driver version 0.9.18 loaded [3.480724] bttv: using 8 buffers with 2080k (520 pages) each for capture [3.507950] bttv: Bt8xx card found (0). [3.513845] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 19 [3.521339] bttv :05:06.0: PCI INT A - Link[LNKC] - GSI 19 (level, low) - IRQ 19 [3.531039] bttv0: Bt878 (rev 17) at :05:06.0, irq: 19, latency: 64, mmio: 0xeefff000 [3.541062] bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb [3.550946] bttv0: using: Hauppauge (bt878) [card=10,autodetected] [3.561433] bttv0: Hauppauge/Voodoo msp34xx: reset line init [5] [3.593765] usb 2-6: new low speed USB device using ohci_hcd and address 2 [3.599016] tveeprom 4-0050: Hauppauge model 61344, rev D421, serial# 3902813 [3.599018] tveeprom 4-0050: tuner model is Philips FM1216 (idx 21, type 5) [3.599021] tveeprom 4-0050: TV standards PAL(B/G) (eeprom 0x04) [3.599022] tveeprom 4-0050: audio processor is MSP3415 (idx 6) [3.599024] tveeprom 4-0050: has radio [3.599025] bttv0: Hauppauge eeprom indicates model#61344 [3.599027] bttv0: tuner type=5 [3.609618] msp3400 4-0040: MSP3415D-B3 found @ 0x80 (bt878 #0 [sw]) [3.609620] msp3400 4-0040: msp3400 supports nicam, mode is autodetect [3.621863] tuner 4-0061: chip found @ 0xc2 (bt878 #0 [sw]) [3.622168] tuner-simple 4-0061: creating new instance [3.622170] tuner-simple 4-0061: type set to 5 (Philips PAL_BG (FI1216 and compatibles)) [3.622882] bttv0: registered device video0 [3.622940] bttv0: registered device vbi0 [3.622997] bttv0: registered device radio0 [3.632337] bttv0: PLL: 28636363 = 35468950 .. ok [3.683096] Registered IR keymap rc-rc5-tv [3.683110] BUG: unable to handle kernel NULL pointer dereference at (null) [3.683113] IP: [813ebe79] ir_register_class+0x59/0x160 [3.683122] PGD 0 [3.683124] Oops: [#1] SMP [3.683125] last sysfs file: [3.683127] CPU 2 [3.683129] Modules linked in: [3.683130] [3.683133] Pid: 1, comm: swapper Not tainted 2.6.35-rc1 #1 KFN5-D SLI/KFN5-D SLI [3.683135] RIP: 0010:[813ebe79] [813ebe79] ir_register_class+0x59/0x160 [3.683139] RSP: 0018:88011ff09cd0 EFLAGS: 00010246 [3.683141] RAX: RBX: 88011f3c1a00 RCX: 81a5baa0 [3.683142] RDX: RSI: 817d24f0 RDI: 88011f3c1a00 [3.683144] RBP: R08: R09: [3.683146] R10: R11: 0021 R12: 817d6960 [3.683147] R13: 88011f223000 R14: 88011f3c1a00 R15: 88011f3c1b40 [3.683150] FS: 010f8870() GS:88008020() knlGS: [3.683151] CS: 0010 DS: ES: CR0: 8005003b [3.683153] CR2: CR3: 01a05000 CR4: 06e0 [3.683155] DR0: DR1: DR2: [3.683157] DR3: DR6: 0ff0 DR7: 0400 [3.683159] Process swapper (pid: 1, threadinfo 88011ff08000, task 88007ff48000) [3.683160] Stack: [3.683162] 88011f223000 81a5ab30 88011f223000 817d6960 [3.683164] 0 0021 813eb90a 88010028 817d240e [3.683166] 0 88011f3c1b68 0282 8800070b54e0 88011f35f100 [3.683169] Call Trace: [3.683174] [813eb90a] ? __ir_input_register+0x2ba/0x350 [3.683178] [8141730a] ? ir_probe+0x36a/0x4f0 [3.683181] [81416fa0] ? ir_probe+0x0/0x4f0 [3.683185] [813d9bca] ? i2c_device_probe+0xea/0x120 [3.683188] [813367aa] ? driver_sysfs_add+0x5a/0x80 [3.683190] [813368d3] ? driver_probe_device+0x83/0x190 [3.683193] [813d9c54] ? i2c_device_match+0x54/0x70 [3.683195] [81336d03] ? __driver_attach+0x93/0xa0 [3.683197] [81336c70] ? __driver_attach+0x0/0xa0 [3.683201] [81335bf8] ? bus_for_each_dev+0x58/0x80 [3.683203] [81335ea0] ? bus_add_driver+0xb0/0x250 [3.683206] [81336e4a] ? driver_register+0x6a/0x130 [3.683209] [812124a0] ? __pci_register_driver+0x80/0xc0 [3.683212] [813daa30] ? i2c_register_driver+0x30/0xb0 [3.683217] [81ae990d] ? bttv_init_module+0x0/0xde [3.683220] [81ae9b09] ? ir_init+0x0/0x14 [3.683224] [810001d4] ? do_one_initcall+0x34/0x190 [3.683227] [81ac36d6] ?
