Re: [em28xx] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 IP: [ffffffffa00997be] :ir_common:ir_input_free+0x26/0x3e
Hello Mauro, With the patch the NULL pointer dereference is fixed. Thx, Sander Sunday, December 6, 2009, 1:53:40 AM, you wrote: Sander Eikelenboom wrote: Hi All, Tried to update my v4l-dvb modules today, but got a bug with my pinnacle card, seems to be related to the recent changes in the ir code. I have added dmesg output of the bug (changeset a871d61b614f tip), and dmesg output of the previous modules (working). -- Sander Dec 5 23:30:25 security kernel: [5.596128] em28xx: New device Pinnacle Systems GmbH PCTV USB2 PAL @ 480 Mbps (2304:0208, interface 0, class 0) Dec 5 23:30:25 security kernel: [5.596535] em28xx #1: chip ID is em2820 (or em2710) Dec 5 23:30:25 security kernel: [5.726154] em28xx #1: i2c eeprom 00: 1a eb 67 95 04 23 08 02 10 00 1e 03 98 1e 6a 2e Dec 5 23:30:25 security kernel: [5.726181] em28xx #1: i2c eeprom 10: 00 00 06 57 6e 00 00 00 8e 00 00 00 07 00 00 00 Dec 5 23:30:25 security kernel: [5.726203] em28xx #1: i2c eeprom 20: 16 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726226] em28xx #1: i2c eeprom 30: 00 00 20 40 20 80 02 20 10 01 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726247] em28xx #1: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726270] em28xx #1: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726290] em28xx #1: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 2e 03 50 00 69 00 Dec 5 23:30:25 security kernel: [5.726312] em28xx #1: i2c eeprom 70: 6e 00 6e 00 61 00 63 00 6c 00 65 00 20 00 53 00 Dec 5 23:30:25 security kernel: [5.726333] em28xx #1: i2c eeprom 80: 79 00 73 00 74 00 65 00 6d 00 73 00 20 00 47 00 Dec 5 23:30:25 security kernel: [5.726354] em28xx #1: i2c eeprom 90: 6d 00 62 00 48 00 00 00 1e 03 50 00 43 00 54 00 Dec 5 23:30:25 security kernel: [5.726376] em28xx #1: i2c eeprom a0: 56 00 20 00 55 00 53 00 42 00 32 00 20 00 50 00 Dec 5 23:30:25 security kernel: [5.726397] em28xx #1: i2c eeprom b0: 41 00 4c 00 00 00 06 03 31 00 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726420] em28xx #1: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726440] em28xx #1: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726461] em28xx #1: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726484] em28xx #1: i2c eeprom f0: 00 00 00 00 00 00 00 00 07 56 d9 35 01 ed 0b f8 Dec 5 23:30:25 security kernel: [5.726506] em28xx #1: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x0fd77740 Dec 5 23:30:25 security kernel: [5.726513] em28xx #1: EEPROM info: Dec 5 23:30:25 security kernel: [5.726517] em28xx #1: AC97 audio (5 sample rates) Dec 5 23:30:25 security kernel: [5.726522] em28xx #1: 500mA max power Dec 5 23:30:25 security kernel: [5.726528] em28xx #1: Table at 0x06, strings=0x1e98, 0x2e6a, 0x Dec 5 23:30:25 security kernel: [5.726534] em28xx #1: Identified as Pinnacle PCTV USB 2 (card=3) Dec 5 23:30:25 security kernel: [5.735698] BUG: unable to handle kernel NULL pointer dereference at Dec 5 23:30:25 security kernel: [5.735716] IP: [a00997be] :ir_common:ir_input_free+0x26/0x3e Dec 5 23:30:25 security kernel: [5.735736] PGD 1fdcb067 PUD 1f65d067 PMD 0 Dec 5 23:30:25 security kernel: [5.735744] Oops: [1] SMP Dec 5 23:30:25 security kernel: [5.735750] CPU 0 Dec 5 23:30:25 security kernel: [5.735754] Modules linked in: ir_kbd_i2c(+) saa7115 usbhid(+) hid ff_memless em28xx(+) v4l2_common videodev v4l1_compat v4l2_compat_ioctl32 ir_common videobuf_vmalloc videobuf_core tveeprom i2c_core evdev ext3 jbd mbcache ohci_hcd ohci1394 ieee1394 ehci_hcd uhci_hcd thermal_sys Dec 5 23:30:25 security kernel: [5.735793] Pid: 1091, comm: modprobe Not tainted 2.6.26-2-xen-amd64 #1 Dec 5 23:30:25 security kernel: [5.735798] RIP: e030:[a00997be] [a00997be] :ir_common:ir_input_free+0x26/0x3e It is weird to call ir_input_free during the boot. This means that something got wrong during IR initialization. Anyway, I think I know here's the bug: the first thing the routine does is this: struct ir_scancode_table *rc_tab = input_get_drvdata(dev); However, if ir_input_init() doesn't initialize fine, rc_tab will be null. Could you please test if the enclosed patch fixes the issue? --- Avoid usage of an initialized drvdata Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/linux/drivers/media/common/ir-keytable.c b/linux/drivers/media/common/ir-keytable.c --- a/linux/drivers/media/common/ir-keytable.c +++
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Dmitry Torokhov wrote:
On Fri, Dec 04, 2009 at 12:12:34PM -0200, Mauro Carvalho Chehab wrote:
Em Fri, 4 Dec 2009 02:06:42 -0800
Dmitry Torokhov dmitry.torok...@gmail.com escreveu:
evdev does not really care what you use as scancode. So nobody stops
your driver to report index as a scancode and accept index from the
ioctl. The true scancode will thus be competely hidden from userspace.
In fact a few drivers do just that.
Let me better express here. It is all about how we'll expand the limits of
those
ioctls to fulfill the needs.
The point is that we'll have, let's say something like to 50-500
scancode/keycode tuples
sparsely spread into a 2^64 scancode universe (assuming 64 bits - Not sure
if is there any
IR protocol/code with a bigger scancode).
On such universe if we want to get all keycodes with the current ioctls for
a scancode in
the range of 32 bits, we need to do something like:
u32 code;
int codes[2];
for (code = 0; code = (unsigned u32) - 1; code++) {
codes[0] = (int)code;
if (!ioctl(fd, EVIOCGKEYCODE, codes))
printf(scancode 0x%08x = keycode 0x%08x\n, codes[0],
codes[1]);
}
So, on the 32 bits case, we'll do about 4 billions calls to EVIOGKEYCODE
ioctl to
read the complete scancode space, to get those 50-500 useful codes.
Right, currently there is no need to query all scancodes defined by
device. Quite often drivers don't even know what scancodes device
actually generates (ex AT keyboard).
Could you describe in more detail how you are using this data?
It is useful if you want to dump the keycode maps into file with the current
scancode attribution, in order to modify some keystrokes.
Right now, programs like dumpkeys (from kbd package) allow you to dump for
example
the attribution keys from your keyboard.
In the case of IR's this functionality is very important.
For example, you may need to replace the scancode/KEY_CHANNELUP tuple by
scancode/KEY_UP,
in order to make your IR to work with some applications that don't recognize
the IR
specific keycodes.
In practice, with such applications, you'll need to replace several different
scancodes.
So, you may end by having different scancodes producing the same keycode, as
such applications
aren't capable of differentiating an UP key from a CHANNELUP key. This is the
case, for example
of the popular tvtime application.
The better way is to just generate a dump file, modify the needed entries and
reload the
table by calling EVIOSKEYCODE, in order to use the new table.
I wrote a small application that just do the above, and I use to load some
special tables
to work with some applications like tvtime and mplayer. (with mplayer, you need
to map
channel down as KEY_H and channel up as KEY_K).
I hope that, after we finish addressing IR's, we'll finally have media
applications handling
directly the proper keycodes, but people may still need to write different
keycodes to do
other things. I used to have a keymap file in order to use an IR to control the
slide show
with openoffice.
Due to the current API limit, we don't have any way to use the full 64bits
space for scancodes.
Can we probably reduce the scancode space? ARe all 64 bits in
protocols used to represent keypresses or some are used for some kind of
addressing?
All the IR's I found with V4L/DVB use up to 16 bits code (or 24 bits, for NEC
extended protocol).
However, currently, the drivers were getting only 7 bits, due to the old way to
implement
EVIO[S|G]KEYCODE.
I know, however, one i2c chip that returns a 5 byte scancode when you press a
key.
We're currently just discarding the remaining bits, so I'm not really sure
what's there.
The usage of 7 bits, in practice, were meaning that it weren't possible to use
a different remote than the one provided by the device manufacturer, as the
scancodes produced
by other remotes differ on more than 7 bits. Also, this means that, if your TV
and your PC
are using the same protocol, like RC5, if you press a button on your TV remote,
the PC will
also get it.
I know, however, one IR driver that produces 6 bytes when you press a key.
We're currently just discarding the remaining bits, so I'm not really sure
what else is there. Some badly optimized protocol? a bigger scancode? a
protocol indication?
In general, the scancode contains 8 or 16 bits for address, and 8 bits for
command.
However, the scancode table needs to handle the address as well, since we don't
want that a
scancode meant to go to your TV to be handled by the PC, but we may want to get
codes from
different addresses there, as we may need to use the address to differentiate
the commands
meant to control the TV volume, for example, than the same command meant to
control the PC
master volume.
if we use code[0] as an index, this means that we'll need to share the 32
bits on code[1]
for scancode/keycode. Even using an 32 bits integer for keycode, it is
currently limited to:
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Dmitry Torokhov wrote: On Fri, Dec 04, 2009 at 12:12:34PM -0200, Mauro Carvalho Chehab wrote: How related lirc-core to the current lirc code? If it is not the same maybe we should not call it lirc to avoid confusion. Just for better illustrate what I'm seeing, I broke the IR generic code into two components: lirc core - the module that receives raw pulse/space and creates a device to receive raw API pulse/space events; IR core - the module that receives scancodes, convert them into keycodes and send via evdev interface. We may change latter the nomenclature, but I'm seeing the core as two different modules, since there are cases where lirc core won't be used (those devices were there's no way to get pulse/space events). OK, I think we are close but not exactly close. I believe that what you call lirc core will be used always - it is the code that create3s class devices, connectes decorers with the data streams, etc. I believe it will be utilized even in case of devices using hardware decoders. That is why we should probably stop calling it lirc core just tso we don't confuse it with original lirc. Then we have decoders and lirc_dev - which implements original lirc interface (or maybe its modified version) and allows lircd to continue working. Lastly we have what you call IR core which is IR-to-input bridge of sorts. It seems to be just nomenclacure ;) what I called IR core you called lirc core what I called lirc core you called lirc_dev What I called IR core is the one that will be used by every IR driver, handling sysfs, evdev's, calling decoders, etc. I opted to use the nomenclature Lirc to the part of the IR subsystem that will create the Lirc interface. Currently, I almost finished the evdev part of the IR core, using the current API to control the dynamic keycode allocation. It is already working fine with V4L drivers. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [em28xx] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 IP: [ffffffffa00997be] :ir_common:ir_input_free+0x26/0x3e
Sander Eikelenboom wrote: Hello Mauro, With the patch the NULL pointer dereference is fixed. Thank you for testing. I've applied the patch on my tree. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Dmitry Torokhov wrote: Hi, On Sun, Dec 06, 2009 at 04:36:33AM +0100, hermann pitton wrote: Hi, Am Freitag, den 04.12.2009, 19:28 -0500 schrieb Jon Smirl: On Fri, Dec 4, 2009 at 6:01 PM, Christoph Bartelmus l...@bartelmus.de wrote: BTW, I just came across a XMP remote that seems to generate 3x64 bit scan codes. Anyone here has docs on the XMP protocol? Assuming a general purpose receiver (not one with fixed hardware decoding), is it important for Linux to receive IR signals from all possible remotes no matter how old or obscure? Or is it acceptable to tell the user to throw away their dedicated remote and buy a universal multi-function one? Universal multi-function remotes are $12 in my grocery store - I don't even have to go to an electronics store. finally we have some point here, IMHO, that is not acceptable and I told you previously not to bet on such. Start some poll and win it, and I'll shut up :) Who would participate in the poll though? To be frank, you are quite mad at this point, or deliver working other remotes to __all__ for free. I do not believe you are being realistic. Sometimes we just need to say that the device is a POS and is just not worth it. Remember, there is still lirc hole for the hard core people still using solder to produce something out of the spare electronic components that may be made to work (never mind that it causes the CPU constantly poll the device, not letting it sleep and wasting electricity as a result - just hypotetical example here). We still need to do cost-benefit analysis and decide whether supporting the exotic setups _in kernel_ makes sense if it encumbers implementation and causes issues to the other 95% people. Fully agreed. The costs (our time) to add and keep supporting an in-kernel driver for an IR that just one person is still using is higher than asking the user to get a new IR. This time would be better spent adding a new driver for other devices. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Hi Dmitry, on 05 Dec 09 at 22:55, Dmitry Torokhov wrote: [...] I do not believe you are being realistic. Sometimes we just need to say that the device is a POS and is just not worth it. Remember, there is still lirc hole for the hard core people still using solder to produce something out of the spare electronic components that may be made to work (never mind that it causes the CPU constantly poll the device, not letting it sleep and wasting electricity as a result - just hypotetical example here). The still seems to be is a persistent misconception that the home-brewn receivers need polling or cause heavy CPU load. No they don't. All of them are IRQ based. It's the commercial solutions like gpio based IR that need polling. For transmitters it's a different story, but you don't transmit 24h/7. Christoph -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Hi Dmitry, on 04 Dec 09 at 15:15, Dmitry Torokhov wrote: [...] http://lirc.sourceforge.net/remotes/lg/6711A20015N This is an air-conditioner remote. The entries that you see in this config file are not really separate buttons. Instead the remote just sends the current settings for e.g. temperature encoded in the protocol when you press some up/down key. You really don't want to map all possible temperature settings to KEY_* events. For such cases it would be nice to have access at the raw scan codes from user space to do interpretation of the data. The default would still be to pass the data to the input layer, but it won't hurt to have the possibility to access the raw data somehow. Interesting. IMHO, the better would be to add an evdev ioctl to return the scancode for such cases, instead of returning the keycode. That means you would have to set up a pseudo keymap, so that you can get the key event which you could than react on with a ioctl. Or are you generating KEY_UNKNOWN for every scancode that is not mapped? What if different scan codes are mapped to the same key event? How do you retrieve the scan code for the key event? I don't think it can work this way. EV_MSC/MSC_SCAN. How would I get the 64 bit scan codes that the iMON devices generate? How would I know that the scan code is 64 bit? input_event.value is __s32. I suppose we could add MSC_SCAN_END event so that we can transmit scancodes of arbitrary length. You'd get several MSC_SCAN followed by MSC_SCAN_END marker. If you don't get MSC_SCAN_END assume the code is 32 bit. And I set a timeout to know that no MSC_SCAN_END will arrive? This is broken design IMHO. Furthermore lircd needs to know the length of the scan code in bits, not as a multiple of 32. FWIW there is MSC_RAW as well. It took me some time to convice people that this is not the right way to handle raw timing data. Christoph -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Hi Jon, on 04 Dec 09 at 19:28, Jon Smirl wrote: BTW, I just came across a XMP remote that seems to generate 3x64 bit scan codes. Anyone here has docs on the XMP protocol? Assuming a general purpose receiver (not one with fixed hardware decoding), is it important for Linux to receive IR signals from all possible remotes no matter how old or obscure? Or is it acceptable to [...] Of course transmitting is a completely different problem, but we haven't been talking about transmitting. I can see how we would need to record any IR protocol in order to retransmit it. But that's in the 5% of users world, not the 90% that want MythTV to just work. Use something like LIRC if you want to transmit. I don't think anyone here is in the position to be able to tell what is 90% or 5%. Personally I use LIRC exclusively for transmit to my settop box using an old and obscure RECS80 protocol. No, I won't replace my setup just because it's old and obscure. Cable companies tend to provide XMP based boxes to subscribers more often these days. Simply not supporting these setups is a no-go for me. Christoph -- 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: Mantis – anyone?
Manu, Thanks for taking care. Please try http://jusst.de/hg/v4l-dvb and report the issues It looks as if dependencies and frontends are not in line. • dependencies for my card’s relevant frontends STB0899, STB6100, and LNBP21 are missing from Kconfig, • dependency for CU1216 is in, but frontend driver source missing. It’s neither in my kernel 2.6.32 sources nor in linuxtv’s v4l-dvb. So, mantis_core is automatically selected and compiled, hopper too, but not mantis. Worked around it by adding/replacing the dependencies (in fact, removing the dependency for CU1216 should have enabled build of mantis). Remaining issues for me: • Can’t lock to 19.2/11303h (looks like something new, related to the change of the transponder’s feed, but other cards – e.g. TBS 6920 and Tevii 470 – do sync without a problem). Looks like a frontend issue to me (STB0899/STB6100), as mantis and budget-ci cards are affected in the same way. This correlates with perfect and quick lock of 19.2/11362h which is about the same frequency and has the same DVB parameters (22000/hC23M5O35S1). • Sometimes very slow lock at transponder change, slow enough to trace it in femon. femon first shows high BER rates and the picture is blocky, reducing within 3 or 4 Seconds to BER=0 and perfect picture. I should be able to repeat that and give you some logs if you need it. • Sometimes lock to a transponder only in certain order of previous transponder. Hard to formalize, though. Verbose module output shows 1 to 2 unsuccessful locking attempts per second by the driver. • Still no 0x-0x SNR and STR range. • Currently no lock on 19.2/12693h either, but this may be a signal quality issue on my side. • Have not yet tried it with two mantis cards in a system, but there was a problem at least with ci handling in such a setup using s2-liplianin for a friend of mine. Will test that next week. • Have not tried IR (I use a radio RCU with lirc). – Matthias -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Sun, Dec 6, 2009 at 7:12 AM, Christoph Bartelmus l...@bartelmus.de wrote: Hi Jon, on 04 Dec 09 at 19:28, Jon Smirl wrote: BTW, I just came across a XMP remote that seems to generate 3x64 bit scan codes. Anyone here has docs on the XMP protocol? Assuming a general purpose receiver (not one with fixed hardware decoding), is it important for Linux to receive IR signals from all possible remotes no matter how old or obscure? Or is it acceptable to [...] Of course transmitting is a completely different problem, but we haven't been talking about transmitting. I can see how we would need to record any IR protocol in order to retransmit it. But that's in the 5% of users world, not the 90% that want MythTV to just work. Use something like LIRC if you want to transmit. I don't think anyone here is in the position to be able to tell what is 90% or 5%. Personally I use LIRC exclusively for transmit to my settop box using an old and obscure RECS80 protocol. No, I won't replace my setup just because it's old and obscure. There are two groups, technically oriented people who can handle messing around with IR protocols and everyone else. I'm not proposing to remove any capabilities from the first group. Instead I'd like to see the creation of a just works option for the other group. We don't know the size of the everyone else group yet because that option doesn't exist. In general non-technical people way out number the technical ones in broad user bases. For example I had to use LIRC to get my remotes working, but I would have rather been in the everyone else group and not had to learn about IR. Cable companies tend to provide XMP based boxes to subscribers more often these days. Simply not supporting these setups is a no-go for me. I suspect what we categorize as just works will expand over time. The in-kernel support can start small and add protocols and maps over time. Support for XMP can start in LIRC and migrate into the kernel after we fully understand the protocol and know that enough people are using it to justify the effort of maintaining it in-kernel. Adding in-kernel support for a protocol is not going to make LIRC disappear. The critical part is getting the initial design of the in-kernel IR system right. That design is very hard to change after it gets into everyone's systems and apps start depending on it. Writing up use cases, modular protocols, figuring out how many bits are needed in fields, how are maps written, can they be autoloaded, transmitting, etc, etc. These are the important things to be discussing. LIRC users obviously have a lot of knowledge in this area to contribute. PS - another area we need to be thinking about is radio remotes like the new RF4CE devices. The button presses from these remotes will come in on the 802.15.4 networking stack and need to get routed into the input subsystem somehow. -- Jon Smirl jonsm...@gmail.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
[PATCH] gspca: make device_table[]s constant
From: Márton Németh nm...@freemail.hu
The device_table structure is used as a constant. The driver_info field
is only copied to the struct sd so it is also not modified.
Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r e16961fe157d linux/drivers/media/video/gspca/conex.c
--- a/linux/drivers/media/video/gspca/conex.c Wed Dec 02 18:39:53 2009 +0100
+++ b/linux/drivers/media/video/gspca/conex.c Sun Dec 06 17:45:02 2009 +0100
@@ -1046,14 +1046,14 @@
};
/* -- module initialisation -- */
-static __devinitdata struct usb_device_id device_table[] = {
+static const struct usb_device_id device_table[] __devinitconst = {
{USB_DEVICE(0x0572, 0x0041)},
{}
};
MODULE_DEVICE_TABLE(usb, device_table);
/* -- device connect -- */
-static int sd_probe(struct usb_interface *intf,
+static int __devinit sd_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
return gspca_dev_probe(intf, id, sd_desc, sizeof(struct sd),
diff -r e16961fe157d linux/drivers/media/video/gspca/etoms.c
--- a/linux/drivers/media/video/gspca/etoms.c Wed Dec 02 18:39:53 2009 +0100
+++ b/linux/drivers/media/video/gspca/etoms.c Sun Dec 06 17:45:02 2009 +0100
@@ -870,7 +870,7 @@
};
/* -- module initialisation -- */
-static __devinitdata struct usb_device_id device_table[] = {
+static const struct usb_device_id device_table[] __devinitconst = {
{USB_DEVICE(0x102c, 0x6151), .driver_info = SENSOR_PAS106},
#if !defined CONFIG_USB_ET61X251 !defined CONFIG_USB_ET61X251_MODULE
{USB_DEVICE(0x102c, 0x6251), .driver_info = SENSOR_TAS5130CXX},
@@ -881,7 +881,7 @@
MODULE_DEVICE_TABLE(usb, device_table);
/* -- device connect -- */
-static int sd_probe(struct usb_interface *intf,
+static int __devinit sd_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
return gspca_dev_probe(intf, id, sd_desc, sizeof(struct sd),
diff -r e16961fe157d linux/drivers/media/video/gspca/pac7302.c
--- a/linux/drivers/media/video/gspca/pac7302.c Wed Dec 02 18:39:53 2009 +0100
+++ b/linux/drivers/media/video/gspca/pac7302.c Sun Dec 06 17:45:02 2009 +0100
@@ -1250,7 +1250,7 @@
};
/* -- module initialisation -- */
-static __devinitdata struct usb_device_id device_table[] = {
+static const struct usb_device_id device_table[] __devinitconst = {
{USB_DEVICE(0x06f8, 0x3009)},
{USB_DEVICE(0x093a, 0x2620)},
{USB_DEVICE(0x093a, 0x2621)},
@@ -1266,7 +1266,7 @@
MODULE_DEVICE_TABLE(usb, device_table);
/* -- device connect -- */
-static int sd_probe(struct usb_interface *intf,
+static int __devinit sd_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
return gspca_dev_probe(intf, id, sd_desc, sizeof(struct sd),
diff -r e16961fe157d linux/drivers/media/video/gspca/pac7311.c
--- a/linux/drivers/media/video/gspca/pac7311.c Wed Dec 02 18:39:53 2009 +0100
+++ b/linux/drivers/media/video/gspca/pac7311.c Sun Dec 06 17:45:03 2009 +0100
@@ -884,7 +884,7 @@
};
/* -- module initialisation -- */
-static __devinitdata struct usb_device_id device_table[] = {
+static const struct usb_device_id device_table[] __devinitconst = {
{USB_DEVICE(0x093a, 0x2600)},
{USB_DEVICE(0x093a, 0x2601)},
{USB_DEVICE(0x093a, 0x2603)},
@@ -896,7 +896,7 @@
MODULE_DEVICE_TABLE(usb, device_table);
/* -- device connect -- */
-static int sd_probe(struct usb_interface *intf,
+static int __devinit sd_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
return gspca_dev_probe(intf, id, sd_desc, sizeof(struct sd),
diff -r e16961fe157d linux/drivers/media/video/gspca/sonixb.c
--- a/linux/drivers/media/video/gspca/sonixb.c Wed Dec 02 18:39:53 2009 +0100
+++ b/linux/drivers/media/video/gspca/sonixb.c Sun Dec 06 17:45:03 2009 +0100
@@ -1256,7 +1256,7 @@
.driver_info = (SENSOR_ ## sensor 8) | BRIDGE_ ## bridge
-static __devinitdata struct usb_device_id device_table[] = {
+static const struct usb_device_id device_table[] __devinitconst = {
{USB_DEVICE(0x0c45, 0x6001), SB(TAS5110, 102)}, /* TAS5110C1B */
{USB_DEVICE(0x0c45, 0x6005), SB(TAS5110, 101)}, /* TAS5110C1B */
#if !defined CONFIG_USB_SN9C102 !defined CONFIG_USB_SN9C102_MODULE
@@ -1287,7 +1287,7 @@
MODULE_DEVICE_TABLE(usb, device_table);
/* -- device connect -- */
-static int sd_probe(struct usb_interface *intf,
+static int __devinit sd_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
return gspca_dev_probe(intf, id, sd_desc, sizeof(struct sd),
diff -r e16961fe157d linux/drivers/media/video/gspca/spca506.c
--- a/linux/drivers/media/video/gspca/spca506.c Wed Dec 02 18:39:53 2009 +0100
+++ b/linux/drivers/media/video/gspca/spca506.c Sun Dec 06 17:45:03 2009 +0100
@@ -685,7 +685,7 @@
};
/* -- module initialisation -- */
-static __devinitdata struct usb_device_id device_table[] = {
+static const struct
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Andy Walls awa...@radix.net writes: Yes, I agree. I do not know what percentage of current Linux users are technical vs non-technical, so I cannot gauge the current improtance. I can see the trend line though: as time goes by, the percentage of all linux users that have a technical bent will only get smaller. This IMHO shouldn't matter. If users can configure their keymaps for e.g. games with a graphical utility (and they easily can), they can do the same with their remotes, at least with these using common sane protocols. The only thing needed is a good GUI utility. Ergo - it's not a kernel issue. The default bundled, or PnP, won't work well in comparison to a GUI utility, I wouldn't worry about it too much (though adding it to udev and co is trivial and we should do it - even if not PnP but asking first about the actual remote used). -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Mauro Carvalho Chehab mche...@redhat.com writes: I do not believe you are being realistic. Sometimes we just need to say that the device is a POS and is just not worth it. Remember, there is still lirc hole for the hard core people still using solder to produce something out of the spare electronic components that may be made to work Which device? It was about a remote controller, not the receiver. The IR receivers are frequently coupled with a DVB etc. receiver. There is absolutely no problem supporting almost any remote if the hardware is compatible with the receiver (i.e. IR to IR, the carrier frequency is not 36 vs 56 kHz, the receiver supports the protocol etc). I don't say we need to support in-kernel decoding for arbitrary protocols. (never mind that it causes the CPU constantly poll the device, not letting it sleep and wasting electricity as a result - just hypotetical example here). Very hypotetical, indeed :-) Most (all?) home-made receivers don't need polling, they use IRQs instead (the home-made receiver is based on serial port and uses IRQ). They are hardly the obscure hardware that nobody has. The more advanced receivers using shift registers may use polling. Fully agreed. The costs (our time) to add and keep supporting an in-kernel driver for an IR that just one person is still using is higher than asking the user to get a new IR. This time would be better spent adding a new driver for other devices. Agreed, I think nobody argues we should support such things in the kernel. Once again: how about agreement about the LIRC interface (kernel-userspace) and merging the actual LIRC code first? In-kernel decoding can wait a bit, it doesn't change any kernel-user interface. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Sun, Dec 6, 2009 at 12:48 PM, Krzysztof Halasa k...@pm.waw.pl wrote: Once again: how about agreement about the LIRC interface (kernel-userspace) and merging the actual LIRC code first? In-kernel decoding can wait a bit, it doesn't change any kernel-user interface. I'd like to see a semi-complete design for an in-kernel IR system before anything is merged from any source. -- Jon Smirl jonsm...@gmail.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
[PATCH -next resend/fixed] media/miro: fix kconfig depends/select
From: Randy Dunlap randy.dun...@oracle.com miropcm20 uses ALSA (snd_) interfaces from the SND_MIRO driver, so it should depend on SND. (selecting SND_MIRO when CONFIG_SND is not enabled is a problem.) drivers/built-in.o: In function `vidioc_s_ctrl': radio-miropcm20.c:(.text+0x227499): undefined reference to `snd_aci_cmd' drivers/built-in.o: In function `vidioc_s_frequency': radio-miropcm20.c:(.text+0x227574): undefined reference to `snd_aci_cmd' radio-miropcm20.c:(.text+0x227588): undefined reference to `snd_aci_cmd' drivers/built-in.o: In function `pcm20_init': radio-miropcm20.c:(.init.text+0x2a784): undefined reference to `snd_aci_get_aci' miropcm20 selects SND_MIRO but SND_ISA may be not enabled, so also select SND_ISA so that the snd-miro driver will be built. Otherwise there are missing symbols: ERROR: snd_opl4_create [sound/isa/opti9xx/snd-miro.ko] undefined! ERROR: snd_wss_pcm [sound/isa/opti9xx/snd-miro.ko] undefined! ERROR: snd_wss_timer [sound/isa/opti9xx/snd-miro.ko] undefined! ERROR: snd_wss_create [sound/isa/opti9xx/snd-miro.ko] undefined! ERROR: snd_wss_mixer [sound/isa/opti9xx/snd-miro.ko] undefined! Signed-off-by: Randy Dunlap randy.dun...@oracle.com --- drivers/media/radio/Kconfig |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- linux-next-20091204.orig/drivers/media/radio/Kconfig +++ linux-next-20091204/drivers/media/radio/Kconfig @@ -197,7 +197,8 @@ config RADIO_MAESTRO config RADIO_MIROPCM20 tristate miroSOUND PCM20 radio - depends on ISA VIDEO_V4L2 + depends on ISA VIDEO_V4L2 SND + select SND_ISA select SND_MIRO ---help--- Choose Y here if you have this FM radio card. You also need to enable -- 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: WARNINGS
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 Dec 6 19:00:09 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13576:121066e283e5 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-armv5: OK linux-2.6.32-armv5-davinci: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-armv5-ixp: OK linux-2.6.32-armv5-ixp: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: OK linux-2.6.32-armv5-omap2: OK linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: OK linux-2.6.31-i686: OK linux-2.6.32-i686: OK linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-m32r: OK linux-2.6.30-mips: OK linux-2.6.31-mips: OK linux-2.6.32-mips: OK linux-2.6.30-powerpc64: OK linux-2.6.31-powerpc64: OK linux-2.6.32-powerpc64: OK linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.11-x86_64: ERRORS linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: OK linux-2.6.31-x86_64: OK linux-2.6.32-x86_64: OK spec: OK sparse (linux-2.6.32): ERRORS linux-2.6.16.61-i686: WARNINGS linux-2.6.17.14-i686: WARNINGS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.61-x86_64: WARNINGS linux-2.6.17.14-x86_64: WARNINGS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
Mauro Carvalho Chehab mche...@redhat.com writes:
All the IR's I found with V4L/DVB use up to 16 bits code (or 24 bits, for NEC
extended protocol).
However, currently, the drivers were getting only 7 bits, due to the old way
to implement
EVIO[S|G]KEYCODE.
I know, however, one i2c chip that returns a 5 byte scancode when you press a
key.
We're currently just discarding the remaining bits, so I'm not really sure
what's there.
Right. This will have to be investigated by owners of the exact hardware
in question. What we can do is to try to make it easy for them.
There is no hurry, though - it can and will continue to work the current
way.
In general, the scancode contains 8 or 16 bits for address, and 8 bits for
command.
Right. I think the kernel shouldn't differentiate between address and
command too much.
at include/linux/input.h, we'll add a code like:
struct input_keytable_entry {
u16 index;
u64 scancode;
u32 keycode;
} __attribute__ ((packed));
(the attribute packed avoids needing a compat for 64 bits)
Maybe { u64 scancode; u32 keycode; u16 index; u16 reserved } would be a
bit better, no alignment problems and we could eventually change
reserved into something useful.
But I think, if we are going to redesign it, we better use scancodes of
arbitrary length (e.g. protocol-dependent length). It should be opaque
except for the protocol handler.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Jon Smirl jonsm...@gmail.com writes: The in-kernel support can start small and add protocols and maps over time. Protocols, yes. Maps - we certainly don't want megatons of maps in the kernel. The existing ones have to be removed, some time. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Jon Smirl jonsm...@gmail.com writes: Once again: how about agreement about the LIRC interface (kernel-userspace) and merging the actual LIRC code first? In-kernel decoding can wait a bit, it doesn't change any kernel-user interface. I'd like to see a semi-complete design for an in-kernel IR system before anything is merged from any source. This is a way to nowhere, there is no logical dependency between LIRC and input layer IR. There is only one thing which needs attention before/when merging LIRC: the LIRC user-kernel interface. In-kernel IR system is irrelevant and, actually, making a correct IR core design without the LIRC merged can be only harder. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Sun, Dec 6, 2009 at 3:34 PM, Krzysztof Halasa k...@pm.waw.pl wrote: Jon Smirl jonsm...@gmail.com writes: Once again: how about agreement about the LIRC interface (kernel-userspace) and merging the actual LIRC code first? In-kernel decoding can wait a bit, it doesn't change any kernel-user interface. I'd like to see a semi-complete design for an in-kernel IR system before anything is merged from any source. This is a way to nowhere, there is no logical dependency between LIRC and input layer IR. There is only one thing which needs attention before/when merging LIRC: the LIRC user-kernel interface. In-kernel IR system is irrelevant and, actually, making a correct IR core design without the LIRC merged can be only harder. Here's a few design review questions on the LIRC drivers that were posted How is the pulse data going to be communicated to user space? Can the pulse data be reported via an existing interface without creating a new one? Where is the documentation for the protocol? Is it a device interface or something else? Does it work with poll, epoll, etc? What is the time standard for the data, where does it come from? How do you define the start and stop of sequences? What about capabilities of the receiver, what frequencies? If a receiver has multiple frequencies, how do you report what frequency the data came in on? What about multiple apps simultaneously using the pulse data? Is receiving synchronous or queued? How big is the receive queue? How does access work, root only or any user? What about transmit, how do you get pulse data into the device? Transmitter frequencies? Multiple transmitters? Is transmitting synchronous or queued? How big is the transmit queue? How are capabilities exposed, sysfs, etc? What is the interface for attaching an in-kernel decoder? If there is an in-kernel decoder should the pulse data stop being reported, partially stopped, something else? What is the mechanism to make sure both system don't process the same pulses? -- Krzysztof Halasa -- Jon Smirl jonsm...@gmail.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: IR Receiver on an Tevii S470
On Sun, 2009-11-22 at 03:03 +0200, Igor M. Liplianin wrote: On 21 ноября 2009 22:41:42 Andy Walls wrote: Matthias Fechner schrieb: I bought some days ago a Tevii S470 DVB-S2 (PCI-E) card and got it running with the driver from: http://mercurial.intuxication.org/hg/s2-liplianin But I was not successfull in got the IR receiver working. It seems that it is not supported yet by the driver. Is there maybe some code available to get the IR receiver with evdev running? If the card is using the built in IR controller in the CX23885, then you'll have to wait until I port my CX23888 IR controller changes to work with the IR controller in the CX23885. That should be somewhat straightforward, but will take time. Then we'll still need you to experiment with a patch. It's cx23885 definitely. Remote uses NEC codes. In any case I can test. On Mon, 2009-11-23, Igor M. Liplianin wrote: Receiver connected to cx23885 IR_RX(pin 106). It is not difficult to track. Igor, As I make patches for test, perhaps you can help answer some questions which will save some experimentation: 1. Does the remote for the TeVii S470 use the same codes as linux/drivers/media/common/ir-keymaps.c : ir_codes_tevii_nec[] or some other remote code table we have in the kernel? 2. Does the remote for the TeVii S470, like other TeVii remotes, use a standard NEC address of 0x00 (so that Addr'Addr is 0xff00) ? Or does it use another address? 3. When you traced board wiring from the IR receiver to the IR_RX pin on the CX23885, did you notice any external components that might modify the signal? For example, a capacitor that integrates carrier bursts into baseband pulses. Thanks. 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 Receiver on an Tevii S470
Hi Andy, Andy Walls wrote: 1. Does the remote for the TeVii S470 use the same codes as linux/drivers/media/common/ir-keymaps.c : ir_codes_tevii_nec[] or some other remote code table we have in the kernel? I don't know how it should work with the kernel but I use the remote together with lirc with the attached config files. Maybe that helps you a little bit. Bye, Matthias -- Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning. -- Rich Cook # # this config file was automatically generated # using lirc-0.8.4(default) on Sun Jul 12 12:05:06 2009 # # contributed by # # brand: TeVii # model no. of remote control: # devices being controlled by this remote: TeVii S650 DVB-S2 USB # begin remote name TeVii_S470 bits 16 flags SPACE_ENC|CONST_LENGTH eps30 aeps 100 header 9032 4440 one 594 1651 zero 594 527 ptrail592 repeat90322212 pre_data_bits 16 pre_data 0xFF gap 107715 toggle_bit_mask 0x8000 begin codes Power0x50AF Mute 0x30CF 10x8877 20x48B7 30xC837 40x28D7 50xA857 60x6897 70xE817 80x18E7 90x9867 00x08F7 recall 0x58A7 fav 0xD827 Vol+ 0x906F Vol- 0xF00F Chan+0x10EF Chan-0x609F ModeLive 0xA05F ModePlay 0xE01F Up 0x00FF Down 0x807F Left 0xC03F Right0x40BF Ok 0xF807 Menu 0x38C7 Back 0xB847 Play 0x02FD FastRew 0x7887 FastFwd 0xB24D EPG 0x22DD Rec 0x20DF Timer0xD02F Open 0x708F Info 0x32CD a/b 0x827D Audio0xC23D subs 0xA25D List 0x52AD F1 0x629D F2 0xE21D F3 0x7A85 F4 0x3AC5 F5 0x4AB5 F6 0x5AA5 mom 0x6A95 fs 0x1AE5 end codes end remote
Re: soc-camera: what's in the queue for 2.6.33
Dear Guennadi Sorry for late response Morimoto-san: I modified a bit your mt9t112 driver, apart from just porting it to the current mediabus version. Please check, if you agree with all changes and if it still works:-) Of course I agree. But sorry I'm very busy this week, so, I can not test it now. I hope it works =) Guennadi Liakhovetski (14): (snip) soc-camera: Add mt9t112 camera driver I think this mt9t112 driver patch should under my name =) Best regards -- Kuninori Morimoto -- 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 Receiver on an Tevii S470
On 6 декабря 2009 23:40:54 Andy Walls wrote: On Sun, 2009-11-22 at 03:03 +0200, Igor M. Liplianin wrote: On 21 ноября 2009 22:41:42 Andy Walls wrote: Matthias Fechner schrieb: I bought some days ago a Tevii S470 DVB-S2 (PCI-E) card and got it running with the driver from: http://mercurial.intuxication.org/hg/s2-liplianin But I was not successfull in got the IR receiver working. It seems that it is not supported yet by the driver. Is there maybe some code available to get the IR receiver with evdev running? If the card is using the built in IR controller in the CX23885, then you'll have to wait until I port my CX23888 IR controller changes to work with the IR controller in the CX23885. That should be somewhat straightforward, but will take time. Then we'll still need you to experiment with a patch. It's cx23885 definitely. Remote uses NEC codes. In any case I can test. On Mon, 2009-11-23, Igor M. Liplianin wrote: Receiver connected to cx23885 IR_RX(pin 106). It is not difficult to track. Igor, Hi Andy, As I make patches for test, perhaps you can help answer some questions which will save some experimentation: 1. Does the remote for the TeVii S470 use the same codes as linux/drivers/media/common/ir-keymaps.c : ir_codes_tevii_nec[] That is correct table for cx88 based TeVii card with the same remote. I believe there is no difference for cx23885. or some other remote code table we have in the kernel? 2. Does the remote for the TeVii S470, like other TeVii remotes, use a standard NEC address of 0x00 (so that Addr'Addr is 0xff00) ? Or does it use another address? Again like in cx88, the address is standard. 3. When you traced board wiring from the IR receiver to the IR_RX pin on the CX23885, did you notice any external components that might modify the signal? For example, a capacitor that integrates carrier bursts into baseband pulses. Yet again I believe there is no capacitors. Very same scheme like in cx88 variants for TeVii and others. Thanks. Regards, Andy -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks -- 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
Success for Compro E650F analog television and alsa sound.
Hi Steve
I'm able to watch now analog television with Compro E650F.
I rich this by merging your cx23885-alsa tree and adding some modifications
for Compro card definition.
Actually, I take it from Mygica definition, only tuner type and DVB port is
different.
Tested with Tvtime.
tvtime | arecord -D hw:2,0 -r 32000 -c 2 -f S16_LE | aplay -
My tv card is third for alsa, so parameter -D for arecord is hw:2,0.
SECAM works well also.
I didn't test component input, though it present in my card.
diff -r 121066e283e5 linux/drivers/media/video/cx23885/Kconfig
--- a/linux/drivers/media/video/cx23885/Kconfig Sun Dec 06 09:32:49 2009 -0200
+++ b/linux/drivers/media/video/cx23885/Kconfig Mon Dec 07 03:48:12 2009 +0200
@@ -1,6 +1,7 @@
config VIDEO_CX23885
tristate Conexant cx23885 (2388x successor) support
- depends on DVB_CORE VIDEO_DEV PCI I2C INPUT
+ depends on DVB_CORE VIDEO_DEV PCI I2C INPUT SND
+ select SND_PCM
select I2C_ALGOBIT
select VIDEO_BTCX
select VIDEO_TUNER
diff -r 121066e283e5 linux/drivers/media/video/cx23885/cx23885-cards.c
--- a/linux/drivers/media/video/cx23885/cx23885-cards.c Sun Dec 06 09:32:49
2009 -0200
+++ b/linux/drivers/media/video/cx23885/cx23885-cards.c Mon Dec 07 03:48:12
2009 +0200
@@ -163,7 +163,29 @@
},
[CX23885_BOARD_COMPRO_VIDEOMATE_E650F] = {
.name = Compro VideoMate E650F,
+ .porta = CX23885_ANALOG_VIDEO,
.portc = CX23885_MPEG_DVB,
+ .tuner_type = TUNER_XC2028,
+ .tuner_addr = 0x61,
+ .input = {
+ {
+ .type = CX23885_VMUX_TELEVISION,
+ .vmux = CX25840_COMPOSITE2,
+ }, {
+ .type = CX23885_VMUX_COMPOSITE1,
+ .vmux = CX25840_COMPOSITE8,
+ }, {
+ .type = CX23885_VMUX_SVIDEO,
+ .vmux = CX25840_SVIDEO_LUMA3 |
+ CX25840_SVIDEO_CHROMA4,
+ }, {
+ .type = CX23885_VMUX_COMPONENT,
+ .vmux = CX25840_COMPONENT_ON |
+ CX25840_VIN1_CH1 |
+ CX25840_VIN6_CH2 |
+ CX25840_VIN7_CH3,
+ },
+ },
},
[CX23885_BOARD_TBS_6920] = {
.name = TurboSight TBS 6920,
--
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 Receiver on an Tevii S470
On Mon, 2009-12-07 at 03:23 +0200, Igor M. Liplianin wrote: On 6 декабря 2009 23:40:54 Andy Walls wrote: On Sun, 2009-11-22 at 03:03 +0200, Igor M. Liplianin wrote: On 21 ноября 2009 22:41:42 Andy Walls wrote: Matthias Fechner schrieb: I bought some days ago a Tevii S470 DVB-S2 (PCI-E) card and got it running with the driver from: http://mercurial.intuxication.org/hg/s2-liplianin But I was not successfull in got the IR receiver working. It seems that it is not supported yet by the driver. Is there maybe some code available to get the IR receiver with evdev running? If the card is using the built in IR controller in the CX23885, then you'll have to wait until I port my CX23888 IR controller changes to work with the IR controller in the CX23885. That should be somewhat straightforward, but will take time. Then we'll still need you to experiment with a patch. It's cx23885 definitely. Remote uses NEC codes. In any case I can test. On Mon, 2009-11-23, Igor M. Liplianin wrote: Receiver connected to cx23885 IR_RX(pin 106). It is not difficult to track. Igor, Hi Andy, As I make patches for test, perhaps you can help answer some questions which will save some experimentation: 1. Does the remote for the TeVii S470 use the same codes as linux/drivers/media/common/ir-keymaps.c : ir_codes_tevii_nec[] That is correct table for cx88 based TeVii card with the same remote. I believe there is no difference for cx23885. or some other remote code table we have in the kernel? 2. Does the remote for the TeVii S470, like other TeVii remotes, use a standard NEC address of 0x00 (so that Addr'Addr is 0xff00) ? Or does it use another address? Again like in cx88, the address is standard. 3. When you traced board wiring from the IR receiver to the IR_RX pin on the CX23885, did you notice any external components that might modify the signal? For example, a capacitor that integrates carrier bursts into baseband pulses. Yet again I believe there is no capacitors. Very same scheme like in cx88 variants for TeVii and others. Igor and Matthias, Please try the changes that I have for the TeVii S470 that are here: http://linuxtv.org/hg/~awalls/cx23885-ir You will want to modprobe the driver modules like this to get debugging information: # modprobe cx25840 ir_debug=2 # modprobe cx23885 ir_input_debug=1 With that debugging you will get output something like this in dmesg or your logs when you press a button on the remote (this is RC-5 using a CX23888 chip not NEC using a CX23885 chip): cx23885[0]/888-ir: IRQ Status: tsr rsr rby cx23885[0]/888-ir: IRQ Enables: rse rte roe cx23885[0]/888-ir: IRQ Status: tsr rsr rby cx23885[0]/888-ir: IRQ Enables: rse rte roe cx23885[0]/888-ir: IRQ Status: tsr rsr rby cx23885[0]/888-ir: IRQ Enables: rse rte roe cx23885[0]/888-ir: IRQ Status: tsr rsr rby cx23885[0]/888-ir: IRQ Enables: rse rte roe cx23885[0]/888-ir: IRQ Status: tsr rsr rby cx23885[0]/888-ir: IRQ Enables: rse rte roe cx23885[0]/888-ir: IRQ Status: tsr rto cx23885[0]/888-ir: IRQ Enables: rse rte roe cx23885[0]/888-ir: rx read: 817000 ns mark cx23885[0]/888-ir: rx read: 838926 ns space cx23885[0]/888-ir: rx read:1572259 ns mark cx23885[0]/888-ir: rx read:1705296 ns space [...] cx23885[0]/888-ir: rx read: 838037 ns space cx23885[0]/888-ir: rx read: 746333 ns mark cx23885[0]/888-ir: rx read:1705741 ns space cx23885[0]/888-ir: rx read:1619370 ns mark cx23885[0]/888-ir: rx read: end of rx NEC would actually have this sort of timing: 8257296 ns mark 4206185 ns space 482926 ns mark 545296 ns space 481296 ns mark 1572259 ns space 481148 ns mark 546333 ns space [...] 433593 ns mark 1618333 ns space 454481 ns mark end of rx 8255519 ns mark 2130926 ns space 480556 ns mark end of rx The NEC decoder will also log the decoded 32 bits it receives and separate out the address and the command bits. If you do not see good or many NEC timing measurments in the logs, the first thing to try is to change lines 533-534 of linux/drivers/media/cx23885/cx23885-input.c: params.modulation = true; params.invert_level = false; If you see no timing measurements or few timing measurements, change the modulation to false. If the chip is expecting carrier pulses and an external circuit or capacitor is smoothing carrier bursts into baseband pulses, then the hardware won't make measurements properly. If you see inverted mark and space inverted when modulation is set to false, then set invert_level to true. Those are the two things I had to really guess at. BTW, I'm not accessing the CX23885 AV Core registers across the I2C bus in a very conservative way. If you notice some
Re: soc-camera: what's in the queue for 2.6.33
On Mon, 7 Dec 2009, Kuninori Morimoto wrote: Dear Guennadi Sorry for late response Morimoto-san: I modified a bit your mt9t112 driver, apart from just porting it to the current mediabus version. Please check, if you agree with all changes and if it still works:-) Of course I agree. But sorry I'm very busy this week, so, I can not test it now. I hope it works =) Guennadi Liakhovetski (14): (snip) soc-camera: Add mt9t112 camera driver I think this mt9t112 driver patch should under my name =) Yes, sorry, I've already corrected it in my local tree. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Sun, Dec 06, 2009 at 09:03:31AM -0200, Mauro Carvalho Chehab wrote:
Dmitry Torokhov wrote:
On Fri, Dec 04, 2009 at 12:12:34PM -0200, Mauro Carvalho Chehab wrote:
Em Fri, 4 Dec 2009 02:06:42 -0800
Dmitry Torokhov dmitry.torok...@gmail.com escreveu:
evdev does not really care what you use as scancode. So nobody stops
your driver to report index as a scancode and accept index from the
ioctl. The true scancode will thus be competely hidden from userspace.
In fact a few drivers do just that.
Let me better express here. It is all about how we'll expand the limits of
those
ioctls to fulfill the needs.
The point is that we'll have, let's say something like to 50-500
scancode/keycode tuples
sparsely spread into a 2^64 scancode universe (assuming 64 bits - Not sure
if is there any
IR protocol/code with a bigger scancode).
On such universe if we want to get all keycodes with the current ioctls
for a scancode in
the range of 32 bits, we need to do something like:
u32 code;
int codes[2];
for (code = 0; code = (unsigned u32) - 1; code++) {
codes[0] = (int)code;
if (!ioctl(fd, EVIOCGKEYCODE, codes))
printf(scancode 0x%08x = keycode 0x%08x\n, codes[0],
codes[1]);
}
So, on the 32 bits case, we'll do about 4 billions calls to EVIOGKEYCODE
ioctl to
read the complete scancode space, to get those 50-500 useful codes.
Right, currently there is no need to query all scancodes defined by
device. Quite often drivers don't even know what scancodes device
actually generates (ex AT keyboard).
Could you describe in more detail how you are using this data?
It is useful if you want to dump the keycode maps into file with the current
scancode attribution, in order to modify some keystrokes.
Right now, programs like dumpkeys (from kbd package) allow you to dump for
example
the attribution keys from your keyboard.
In the case of IR's this functionality is very important.
For example, you may need to replace the scancode/KEY_CHANNELUP tuple by
scancode/KEY_UP,
in order to make your IR to work with some applications that don't recognize
the IR
specific keycodes.
In practice, with such applications, you'll need to replace several different
scancodes.
So, you may end by having different scancodes producing the same keycode, as
such applications
aren't capable of differentiating an UP key from a CHANNELUP key. This is the
case, for example
of the popular tvtime application.
The better way is to just generate a dump file, modify the needed entries and
reload the
table by calling EVIOSKEYCODE, in order to use the new table.
I wrote a small application that just do the above, and I use to load some
special tables
to work with some applications like tvtime and mplayer. (with mplayer, you
need to map
channel down as KEY_H and channel up as KEY_K).
I hope that, after we finish addressing IR's, we'll finally have media
applications handling
directly the proper keycodes, but people may still need to write different
keycodes to do
other things. I used to have a keymap file in order to use an IR to control
the slide show
with openoffice.
Due to the current API limit, we don't have any way to use the full 64bits
space for scancodes.
Can we probably reduce the scancode space? ARe all 64 bits in
protocols used to represent keypresses or some are used for some kind of
addressing?
All the IR's I found with V4L/DVB use up to 16 bits code (or 24 bits, for NEC
extended protocol).
However, currently, the drivers were getting only 7 bits, due to the old way
to implement
EVIO[S|G]KEYCODE.
I know, however, one i2c chip that returns a 5 byte scancode when you press a
key.
We're currently just discarding the remaining bits, so I'm not really sure
what's there.
The usage of 7 bits, in practice, were meaning that it weren't possible to use
a different remote than the one provided by the device manufacturer, as the
scancodes produced
by other remotes differ on more than 7 bits. Also, this means that, if your
TV and your PC
are using the same protocol, like RC5, if you press a button on your TV
remote, the PC will
also get it.
I know, however, one IR driver that produces 6 bytes when you press a key.
We're currently just discarding the remaining bits, so I'm not really sure
what else is there. Some badly optimized protocol? a bigger scancode? a
protocol indication?
In general, the scancode contains 8 or 16 bits for address, and 8 bits for
command.
However, the scancode table needs to handle the address as well, since we
don't want that a
scancode meant to go to your TV to be handled by the PC, but we may want to
get codes from
different addresses there, as we may need to use the address to differentiate
the commands
meant to control the TV volume, for example, than the same command meant to
control the PC
master volume.
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Sun, Dec 06, 2009 at 12:58:00PM +0100, Christoph Bartelmus wrote: Hi Dmitry, on 04 Dec 09 at 15:15, Dmitry Torokhov wrote: [...] http://lirc.sourceforge.net/remotes/lg/6711A20015N This is an air-conditioner remote. The entries that you see in this config file are not really separate buttons. Instead the remote just sends the current settings for e.g. temperature encoded in the protocol when you press some up/down key. You really don't want to map all possible temperature settings to KEY_* events. For such cases it would be nice to have access at the raw scan codes from user space to do interpretation of the data. The default would still be to pass the data to the input layer, but it won't hurt to have the possibility to access the raw data somehow. Interesting. IMHO, the better would be to add an evdev ioctl to return the scancode for such cases, instead of returning the keycode. That means you would have to set up a pseudo keymap, so that you can get the key event which you could than react on with a ioctl. Or are you generating KEY_UNKNOWN for every scancode that is not mapped? What if different scan codes are mapped to the same key event? How do you retrieve the scan code for the key event? I don't think it can work this way. EV_MSC/MSC_SCAN. How would I get the 64 bit scan codes that the iMON devices generate? How would I know that the scan code is 64 bit? input_event.value is __s32. I suppose we could add MSC_SCAN_END event so that we can transmit scancodes of arbitrary length. You'd get several MSC_SCAN followed by MSC_SCAN_END marker. If you don't get MSC_SCAN_END assume the code is 32 bit. And I set a timeout to know that no MSC_SCAN_END will arrive? This is broken design IMHO. EV_SYN signals the end of state transmission. Furthermore lircd needs to know the length of the scan code in bits, not as a multiple of 32. I really do not think that LIRCD is the type of application that should be using evdev interface, but rather other way around. FWIW there is MSC_RAW as well. It took me some time to convice people that this is not the right way to handle raw timing data. Christoph -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
