Re: [PATCH 1/2 v3] v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats
Hi Hans
On Wed, 2 Dec 2009, Hans Verkuil wrote:
On Tuesday 01 December 2009 16:22:55 Guennadi Liakhovetski wrote:
On Tue, 1 Dec 2009, Hans Verkuil wrote:
On Monday 30 November 2009 14:49:07 Guennadi Liakhovetski wrote:
Right, how about this:
/*
* These pixel codes uniquely identify data formats on the media bus.
Mostly * they correspond to similarly named V4L2_PIX_FMT_* formats,
format 0 is * reserved, V4L2_MBUS_FMT_FIXED shall be used by
host-client pairs, where the * data format is fixed. Additionally,
2X8 means that one pixel is transferred * in two 8-bit samples, BE
or LE specify in which order those samples are * transferred over the
bus: LE means that the least significant bits are * transferred
first, BE means that the most significant bits are transferred *
first, and PADHI and PADLO define which bits - low or high, in the
* incomplete high byte, are filled with padding bits.
*/
enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_FIXED = 1,
V4L2_MBUS_FMT_YUYV_2X8_LE,
V4L2_MBUS_FMT_YVYU_2X8_LE,
V4L2_MBUS_FMT_UYVY_2X8_LE,
V4L2_MBUS_FMT_VYUY_2X8_LE,
These possibly may need a comment saying that each Y/U/V sample is 8 bits
wide. I'm not sure how far we want to go with systematic naming schemes
here. Adding a short comment if there is a possible ambiguity is probably
sufficient.
Is there an ambiguity? Aren't these formats standardised?
HDMI receivers/transmitters can do YUV with 8, 10 or 12 bits. So when you say
YUYV_2X8_LE do you mean that 10 bits are transported over two bytes, or that
a Y and a U (or V) are transferred one after another? From the absence of a
PADHI or PADLO I can infer that it is the latter, but it is not exactly
obvious.
Actually, why not name these formats YUYV8, etc. and the order of the bytes
going over the bus is just the order of the text 'YUYV'. There is not really
any big or little endian issues since you just need to know the sequence of
Ys, Us and Vs.
Ok, we could keep discussing these things for a while, but I don't think
we have that time, and it's not _that_ important to me what these things
will be called - will use whatever names there are.
Just to explain 2X8 - this notation comes from packing and means, to get
one _pixel_ you need two 8-bit wide samples. With YUYV one pixel is
defined as YU or YV, so, that gives you (at most) 8 bits per component.
Ok, I'm planning to submit a version of this patch a bit later today with
names like
enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_FIXED = 1,
V4L2_MBUS_FMT_YUYV8,
V4L2_MBUS_FMT_YVYU8,
according to your last suggestion.
Do we then have
to explain what rgb555 means etc?
V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE,
V4L2_MBUS_FMT_RGB555X_2X8_PADHI_LE,
Shouldn't this be: V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE? Since the 555X
format is just the big-endian variant of the RGB555 if I am not mistaken.
No, don't think so. As an RGB555X format it is sent in LE order, if you
send RGB555X in BE order you get RGB555 (without an X). In fact, you'll
never have a RGB555X_BE format, because, that's just the RGB555_LE. So,
you may only have BE variants for formats, whoch byte-swapped variants do
not have an own name.
RGB 5:5:5 consists of 16 bits argg gggb ('a' is either padding or an
alpha bit).
From what I read, RGB555 has high bit unused. With the alpha bit (or
transparency bit) it's already RGBA or RGBT.
RGB 5:5:5 over an 8 bit data bus is either with the MSB byte first (big
endian
aka RGB555X aka RGB555_2X8_PADHI_BE) or with the LSB byte first (little
endian
aka RGB555 aka RGB555_2X8_PADHI_LE).
The use of RGB555X in the pixel formats is a really ugly accident of history.
'RGB555' is the name of the format, and _LE or _BE should define what the
order of the LSB and MSB over the data bus is.
So, I'll make them
V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE,
V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE,
and 555X will just vanish?
V4L2_MBUS_FMT_RGB565_2X8_LE,
V4L2_MBUS_FMT_RGB565X_2X8_LE,
Ditto.
V4L2_MBUS_FMT_SBGGR8_1X8,
V4L2_MBUS_FMT_SBGGR10_1X10,
V4L2_MBUS_FMT_GREY_1X8,
This is also 8 bits per sample, right? This might be renamed to
GREY8_1X8.
I named it after V4L2_PIX_FMT_GREY. If we ever get GREY7 or similar, I
think, we anyway will need a new fourcc code for it, then we'll call the
MBUS_FMT similarly.
Why not do it right from the start? Frankly, the PIX_FMT names aren't that
great. And since this will become a public API in the future I think it is
reasonable to spend some time on it (and it is the reason why I'm so picky
about it :-) ).
The whole then becomes:
/*
* These pixel codes uniquely identify data formats on the media bus. Mostly
* they correspond to similarly named V4L2_PIX_FMT_*
Re: dvb_usb_dib0700 ( T14BR) not initializing on reboot
Vendor is below: usb 1-8: New USB device found, idVendor=05d8, idProduct=810f usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Note it does work as I said AFTER boot is complete but not if its plugged in during the boot phase.. so i must be something to do with how USB is initialised perhaps? Note it does work sometimes during reboot so perhaps some timing issue during init? thanks Paul On 2/12/2009 6:28 PM, ALi wrote: Are you sure that your usb is dib0700? if you look on the sources you wont see idVendor=413c, idProduct=3010 however there is os...@x-evian:/usr/src/linux-source-2.6.30/drivers/media/dvb/dvb-usb$ grep 05d8 * -iR Coincidencia en el fichero binario dvb-usb-dib0700.ko dvb-usb-dib0700.mod.c:MODULE_ALIAS(usb:v05D8p810Fd*dc*dsc*dp*ic*isc*ip*); in the file so try to recompile it with your device id, and pray for it :) On Wed, Dec 2, 2009 at 5:15 AM, Paul myli...@wilsononline.id.au wrote: On 2/12/2009 12:35 PM, Paul wrote: I have a DVB-T USB device ( T14BR), which seems to work fine when I plug in my Fedora 10 box but I if I reboot with device connected it regularity fails to initialise correctly and to correct I have to remove unplug-device remove the module and reload module to fix up and only after system has been fully booted eg modprobe -r dvb-usb-dib0700 then modprobe dvb-usb-dib0700 adapter_nr=2 and then plug device in. I get the following msgs when it seems to fail and the second set when it works kernel log (failed) Nov 22 13:51:50 mythbox kernel: usb 2-7: new full speed USB device using ohci_hcd and address 2 Nov 22 13:51:50 mythbox kernel: usb 2-7: new full speed USB device using ohci_hcd and address 3 Nov 22 13:51:50 mythbox kernel: usb 2-7: new full speed USB device using ohci_hcd and address 4 Nov 22 13:51:50 mythbox kernel: usb 2-7: new full speed USB device using ohci_hcd and address 5 Nov 22 13:51:50 mythbox kernel: usb 2-8: new low speed USB device using ohci_hcd and address 6 Nov 22 13:51:50 mythbox kernel: usb 2-8: configuration #1 chosen from 1 choice Nov 22 13:51:50 mythbox kernel: usb 2-8: New USB device found, idVendor=413c, idProduct=3010 Nov 22 13:51:50 mythbox kernel: usb 2-8: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Nov 22 13:51:50 mythbox kernel: usbcore: registered new interface driver hiddev Nov 22 13:51:50 mythbox kernel: input: HID 413c:3010 as /devices/pci:00/:00:02.0/usb2/2-8/2-8:1.0/input/input4 Nov 22 13:51:50 mythbox kernel: input,hidraw0: USB HID v1.00 Mouse [HID 413c:3010] on usb-:00:02.0-8 Nov 22 13:51:50 mythbox kernel: usbcore: registered new interface driver usbhid Nov 22 13:51:50 mythbox kernel: usbhid: v2.6:USB HID core driver http://www.artectv.com/ehtm/products/t14.htm kernel log (working) Nov 29 09:58:20 mythbox kernel: usb 1-8: new high speed USB device using ehci_hcd and address 3 Nov 29 09:58:20 mythbox kernel: usb 1-8: configuration #1 chosen from 1 choice Nov 29 09:58:20 mythbox kernel: usb 1-8: New USB device found, idVendor=05d8, idProduct=810f Nov 29 09:58:20 mythbox kernel: usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Nov 29 09:58:20 mythbox kernel: usb 1-8: Product: ART7070 Nov 29 09:58:20 mythbox kernel: usb 1-8: Manufacturer: Ultima Nov 29 09:58:20 mythbox kernel: usb 1-8: SerialNumber: 001 Nov 29 09:58:20 mythbox kernel: dib0700: loaded with support for 7 different device-types Nov 29 09:58:20 mythbox kernel: dvb-usb: found a 'Artec T14BR DVB-T' in cold state, will try to load a firmware Nov 29 09:58:20 mythbox kernel: firmware: requesting dvb-usb-dib0700-1.10.fw Nov 29 09:58:20 mythbox kernel: dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.10.fw' Nov 29 09:58:22 mythbox kernel: dib0700: firmware started successfully. Nov 29 09:58:23 mythbox kernel: dvb-usb: found a 'Artec T14BR DVB-T' in warm state. Nov 29 09:58:23 mythbox kernel: dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Nov 29 09:58:23 mythbox kernel: DVB: registering new adapter (Artec T14BR DVB-T) Nov 29 09:58:23 mythbox kernel: DiB0070: successfully identified Nov 29 09:58:23 mythbox kernel: input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:02.1/usb1/1 -8/input/input7 Nov 29 09:58:23 mythbox kernel: dvb-usb: schedule remote query interval to 150 msecs. Nov 29 09:58:23 mythbox kernel: dvb-usb: Artec T14BR DVB-T successfully initialized and connected. Note I googled a few other people with the same issue: http://www.linuxtv.org/pipermail/linux-dvb/2007-November/022145.html http://ubuntuforums.org/archive/index.php/t-1233131.html so I'm assuming its a known issue, right? Paul -- 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
Re: [RFC v2] Another approach to IR
On Tue, Dec 01, 2009 at 07:05:49PM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote: For sure we need to add an EVIOSETPROTO ioctl to allow the driver to change the protocol in runtime. Mauro, I think this kind of confuguration belongs to lirc device space, not input/evdev. This is the same as protocol selection for psmouse module: while it is normally auto-detected we have sysfs attribute to force one or another and it is tied to serio device, not input device. Dmitry, This has nothing to do with the raw interface nor with lirc. This problem happens with the evdev interface and already affects the in-kernel drivers. In this case, psmouse is not a good example. With a mouse, when a movement occurs, you'll receive some data from its port. So, a software can autodetect the protocol. The same principle can be used also with a raw pulse/space interface, where software can autodetect the protocol. Or, in certain cases, it can not. [... skipped rationale for adding a way to control protocol (with which I agree) ...] To solve this, we really need to extend evdev API to do 3 things: enumberate the supported protocols, get the current protocol(s), and select the protocol(s) that will be used by a newer table. And here we start disagreeing. My preference would be for adding this API on lirc device level (i.e. /syc/class/lirc/lircX/blah namespace), since it only applicable to IR, not to input devices in general. Once you selected proper protocol(s) and maybe instantiated several input devices then udev (by examining input device capabilities and optionally looking up at the parent device properties) would use input evdev API to load proper keymap. Because translation of driver-specific codes into standard key definitions is in the input realm. Reading these driver-specific codes from hardware is outside of input layer domain. Just as psmouse ability to specify protocol is not shoved into evdev; just as atkbd quirks (force release key list and other driver-specific options) are not in evdev either; we should not overload evdev interface with IR-specific items. I'm not against mapping those features as sysfs atributes, but they don't belong to lirc, as far as I understand. From all we've discussed, we'll create a lirc interface to allow the direct usage of raw IO. However, IR protocol is a property that is not related to raw IO mode but, instead, to evdev mode. Why would protocol relate to evdev node? Evdev does not really care what how the fact that a certain button was pressed was communicated to it. It may be deliveretd through PS/2 port, or maybe it was Bluetooth HID, or USB HID or USB boot protocol or some custom protocol, or RC-5, NEC or some custom IR protocol. It makes no difference _whatsoever_ to evdev nor any users of evdev care about protocol used by underlying hardware device to transmit the data. We might add a /sys/class/IR and add IR specific stuff there, but it seems overkill to me and will hide the fact that those parameters are part of the evdev interface. So, I would just add the IR sysfs parameters at the /sys/class/input, if the device is an IR (or create it is /sys/class/input/IR). I agree that the code to implement the IR specific sysfs parameter should be kept oustide input core, as they're specific to IR implementations. Would this work for you? I am seeing a little bit differently structured subsystem for IR at the moment. I think we should do something like this: - receivers create /sys/class/lirc devices. These devices provide API with a ring buffer (fifo) for the raw data stream coming from (and to) them. - we allow registering several data interfaces/decoders that can be bound (manually or maybe automatically) to lirc devices. lirc devices may provide hints as to which interface(s) better suited for handling the data coming form particular receiver. Several interfaces may be bound to one device at a time. - one of the interfaces is interface implementing current lirc_dev - other interfaces may be in-kernel RC-5 decoder or other decoders. decoders will create instances of input devices (for each remote/substream that they can recognize). This way there is clear layering, protocol selection is kept at lirc level. Would this work? -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] Another approach to IR
On 12/01/09 22:05, Mauro Carvalho Chehab wrote: So, I would just add the IR sysfs parameters at the /sys/class/input, if the device is an IR (or create it is /sys/class/input/IR). No, you add it to the physical device node. The usb mouse on the system I'm working on is here: zweiblum kraxel $ ll /sys/class/input/ | grep usb2 lrwxrwxrwx. 1 root root 0 Dec 2 12:07 event7 - ../../devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0/input/input7/event7/ lrwxrwxrwx. 1 root root 0 Dec 2 12:07 input7 - ../../devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0/input/input7/ lrwxrwxrwx. 1 root root 0 Dec 2 12:07 mouse2 - ../../devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0/input/input7/mouse2/ So /sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0 is the device node of the physical device, and the input devices belonging to it are in the input subdirectory. If the mouse would be a usb IR receiver the IR attributes should go to /sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0 or maybe a 'ir' subdirectory there. HTH, Gerd -- 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 v2] Another approach to IR
Dmitry Torokhov wrote: On Tue, Dec 01, 2009 at 07:05:49PM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote: For sure we need to add an EVIOSETPROTO ioctl to allow the driver to change the protocol in runtime. Mauro, I think this kind of confuguration belongs to lirc device space, not input/evdev. This is the same as protocol selection for psmouse module: while it is normally auto-detected we have sysfs attribute to force one or another and it is tied to serio device, not input device. Dmitry, This has nothing to do with the raw interface nor with lirc. This problem happens with the evdev interface and already affects the in-kernel drivers. In this case, psmouse is not a good example. With a mouse, when a movement occurs, you'll receive some data from its port. So, a software can autodetect the protocol. The same principle can be used also with a raw pulse/space interface, where software can autodetect the protocol. Or, in certain cases, it can not. [... skipped rationale for adding a way to control protocol (with which I agree) ...] To solve this, we really need to extend evdev API to do 3 things: enumberate the supported protocols, get the current protocol(s), and select the protocol(s) that will be used by a newer table. And here we start disagreeing. My preference would be for adding this API on lirc device level (i.e. /syc/class/lirc/lircX/blah namespace), since it only applicable to IR, not to input devices in general. Once you selected proper protocol(s) and maybe instantiated several input devices then udev (by examining input device capabilities and optionally looking up at the parent device properties) would use input evdev API to load proper keymap. Because translation of driver-specific codes into standard key definitions is in the input realm. Reading these driver-specific codes from hardware is outside of input layer domain. Just as psmouse ability to specify protocol is not shoved into evdev; just as atkbd quirks (force release key list and other driver-specific options) are not in evdev either; we should not overload evdev interface with IR-specific items. I'm not against mapping those features as sysfs atributes, but they don't belong to lirc, as far as I understand. From all we've discussed, we'll create a lirc interface to allow the direct usage of raw IO. However, IR protocol is a property that is not related to raw IO mode but, instead, to evdev mode. Why would protocol relate to evdev node? Evdev does not really care what how the fact that a certain button was pressed was communicated to it. It may be deliveretd through PS/2 port, or maybe it was Bluetooth HID, or USB HID or USB boot protocol or some custom protocol, or RC-5, NEC or some custom IR protocol. It makes no difference _whatsoever_ to evdev nor any users of evdev care about protocol used by underlying hardware device to transmit the data. We might add a /sys/class/IR and add IR specific stuff there, but it seems overkill to me and will hide the fact that those parameters are part of the evdev interface. So, I would just add the IR sysfs parameters at the /sys/class/input, if the device is an IR (or create it is /sys/class/input/IR). I agree that the code to implement the IR specific sysfs parameter should be kept oustide input core, as they're specific to IR implementations. Would this work for you? I am seeing a little bit differently structured subsystem for IR at the moment. I think we should do something like this: - receivers create /sys/class/lirc devices. These devices provide API with a ring buffer (fifo) for the raw data stream coming from (and to) them. The raw interface applies only to the devices that doesn't have a hardware decoder (something between 40%-60% of the currently supported devices). - we allow registering several data interfaces/decoders that can be bound (manually or maybe automatically) to lirc devices. lirc devices may provide hints as to which interface(s) better suited for handling the data coming form particular receiver. Several interfaces may be bound to one device at a time. - one of the interfaces is interface implementing current lirc_dev - other interfaces may be in-kernel RC-5 decoder or other decoders. decoders will create instances of input devices I don't see why having more than one interface, especially for devices with hardware decoders. On IR remote receivers, internally, there's just one interface per hardware. Considering the hardware decoding case, why to artificially create other interfaces that can't be used simultaneously? No current hardware decoders can do that (or, at least, no current implementation allows). We're foreseen some cases where we'll have that (like
Re: [RFC v2] Another approach to IR
Gerd Hoffmann wrote: On 12/01/09 22:05, Mauro Carvalho Chehab wrote: So, I would just add the IR sysfs parameters at the /sys/class/input, if the device is an IR (or create it is /sys/class/input/IR). No, you add it to the physical device node. The usb mouse on the system I'm working on is here: zweiblum kraxel $ ll /sys/class/input/ | grep usb2 lrwxrwxrwx. 1 root root 0 Dec 2 12:07 event7 - ../../devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0/input/input7/event7/ lrwxrwxrwx. 1 root root 0 Dec 2 12:07 input7 - ../../devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0/input/input7/ lrwxrwxrwx. 1 root root 0 Dec 2 12:07 mouse2 - ../../devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0/input/input7/mouse2/ So /sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0 is the device node of the physical device, and the input devices belonging to it are in the input subdirectory. If the mouse would be a usb IR receiver the IR attributes should go to /sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0 or maybe a 'ir' subdirectory there. This makes sense to me. 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: [resend] radio-sf16fmi: fix mute, add SF16-FMP to texts
On Tuesday 01 December 2009, Petr Vandrovec wrote:
Ondrej Zary wrote:
Fix completely broken mute handling radio-sf16fmi.
The sound was muted immediately after tuning in KRadio.
Also fix typos and add SF16-FMP to the texts.
I do not have device anymore. Looks OK to me.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
Acked-by: Petr Vandrovec p...@vandrovec.name
To whom should I forward this (and your second patch), I did not do any
SF16 work for 10 years (and no LKML for 3).
No one seems to care here on linux-media :(
Thanks,
Petr
diff -urp linux-source-2.6.31-orig/drivers/media/radio/Kconfig
linux-source-2.6.31/drivers/media/radio/Kconfig ---
linux-source-2.6.31-orig/drivers/media/radio/Kconfig2009-09-10
00:13:59.0 +0200 +++
linux-source-2.6.31/drivers/media/radio/Kconfig 2009-11-28
11:51:42.0 +0100 @@ -196,7 +196,7 @@ config RADIO_MAESTRO
module will be called radio-maestro.
config RADIO_SF16FMI
- tristate SF16FMI Radio
+ tristate SF16-FMI/SF16-FMP Radio
depends on ISA VIDEO_V4L2
---help---
Choose Y here if you have one of these FM radio cards. If you
diff -urp linux-source-2.6.31-orig/drivers/media/radio/radio-sf16fmi.c
linux-source-2.6.31/drivers/media/radio/radio-sf16fmi.c ---
linux-source-2.6.31-orig/drivers/media/radio/radio-sf16fmi.c
2009-09-10
00:13:59.0 +0200 +++
linux-source-2.6.31/drivers/media/radio/radio-sf16fmi.c 2009-11-28
11:39:35.0 +0100 @@ -1,4 +1,4 @@
-/* SF16FMI radio driver for Linux radio support
+/* SF16-FMI and SF16-FMP radio driver for Linux radio support
* heavily based on rtrack driver...
* (c) 1997 M. Kirkwood
* (c) 1998 Petr Vandrovec, vandr...@vc.cvut.cz
@@ -11,7 +11,7 @@
*
* Frequency control is done digitally -- ie
out(port,encodefreq(95.8)); * No volume control - only mute/unmute - you
have to use line volume - * control on SB-part of SF16FMI
+ * control on SB-part of SF16-FMI/SF16-FMP
*
* Converted to V4L2 API by Mauro Carvalho Chehab
mche...@infradead.org */
@@ -30,14 +30,14 @@
#include media/v4l2-ioctl.h
MODULE_AUTHOR(Petr Vandrovec, vandr...@vc.cvut.cz and M. Kirkwood);
-MODULE_DESCRIPTION(A driver for the SF16MI radio.);
+MODULE_DESCRIPTION(A driver for the SF16-FMI and SF16-FMP radio.);
MODULE_LICENSE(GPL);
static int io = -1;
static int radio_nr = -1;
module_param(io, int, 0);
-MODULE_PARM_DESC(io, I/O address of the SF16MI card (0x284 or 0x384));
+MODULE_PARM_DESC(io, I/O address of the SF16-FMI or SF16-FMP card
(0x284 or 0x384)); module_param(radio_nr, int, 0);
#define RADIO_VERSION KERNEL_VERSION(0, 0, 2)
@@ -47,7 +47,7 @@ struct fmi
struct v4l2_device v4l2_dev;
struct video_device vdev;
int io;
- int curvol; /* 1 or 0 */
+ bool mute;
unsigned long curfreq; /* freq in kHz */
struct mutex lock;
};
@@ -105,7 +105,7 @@ static inline int fmi_setfreq(struct fmi
outbits(8, 0xC0, fmi-io);
msleep(143);/* was schedule_timeout(HZ/7) */
mutex_unlock(fmi-lock);
- if (fmi-curvol)
+ if (!fmi-mute)
fmi_unmute(fmi);
return 0;
}
@@ -116,7 +116,7 @@ static inline int fmi_getsigstr(struct f
int res;
mutex_lock(fmi-lock);
- val = fmi-curvol ? 0x08 : 0x00;/* unmute/mute */
+ val = fmi-mute ? 0x00 : 0x08; /* mute/unmute */
outb(val, fmi-io);
outb(val | 0x10, fmi-io);
msleep(143);/* was schedule_timeout(HZ/7) */
@@ -204,7 +204,7 @@ static int vidioc_g_ctrl(struct file *fi
switch (ctrl-id) {
case V4L2_CID_AUDIO_MUTE:
- ctrl-value = fmi-curvol;
+ ctrl-value = fmi-mute;
return 0;
}
return -EINVAL;
@@ -221,7 +221,7 @@ static int vidioc_s_ctrl(struct file *fi
fmi_mute(fmi);
else
fmi_unmute(fmi);
- fmi-curvol = ctrl-value;
+ fmi-mute = ctrl-value;
return 0;
}
return -EINVAL;
--
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: [resend] radio-sf16fmi: fix mute, add SF16-FMP to texts
Hi Ondrej, 2009/12/2 Ondrej Zary li...@rainbow-software.org: On Tuesday 01 December 2009, Petr Vandrovec wrote: Ondrej Zary wrote: Fix completely broken mute handling radio-sf16fmi. The sound was muted immediately after tuning in KRadio. Also fix typos and add SF16-FMP to the texts. I do not have device anymore. Looks OK to me. Signed-off-by: Ondrej Zary li...@rainbow-software.org Acked-by: Petr Vandrovec p...@vandrovec.name To whom should I forward this (and your second patch), I did not do any SF16 work for 10 years (and no LKML for 3). No one seems to care here on linux-media :( I recommend to wait a bit more. You seems jumped directly to time when maintainers are busy with 2.6.32 release. Mauro usually answers asap. /Honza -- 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
TBS 6980 Dual DVB-S2 PCIe card
Hello, Is someone already working on supporting the TBS 6980 Dual DVB-S2 PCIe card? http://www.tbsdtv.com/english/product/6980.html Chips in use appear to be: - Conexant CX23885 (PCI Express bridge) - NXP/Conexant CX24132 (DVB-S/S2 tuner) - NXP/Conexant CX24117 (DVB-S/S2 demodulator) I know there is code in v4l-dvb for the CX23885 but I don't think I've seen any for the CX24132 and CX24117. Any insight into supporting this card would be great Thanks Thomas -- 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: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
On Tue, Dec 1, 2009 at 4:18 AM, Vincent McIntyre vincent.mcint...@gmail.com wrote: Hi Rob I missed your followup and tested the 'revert.diff' patch, attached for reference. I have been slow replying because I've been scratching my head over the results. I used 'signaltest.pl' to test[1], which uses tzap under the hood. Perhaps this is not the best choice, but I wanted something that I thought would allow objective comparisons. That's trickier than I thought... Unfortunately I only discovered last night how easy 'vlc ./channels.conf' makes doing quick visual checks. I didn't have enough time to re-patch and test again. My test procedure was: - get a baseline with tzap and signaltest.pl - patch, make, install. cold boot. - test with tzap and signaltest.pl - revert patch, for the moment. I tested two kernels, and both cards. I tested all the tuners but I'll spare you that for now. * 2.6.24-23-rt + v4l (c57f47cfb0e8+ tip) I got rather different baseline results. All channels had significantly higher BER than I'd noticed before. After patching, snr on some channels seemed a little higher and BER was lower. On ch9, I think snr was up and BER improved a little. here are the signaltest summary tables: without patch. usb device (dvb0) usbid db78:0fe9 Frequency Signal Ber Unc = 17750 76.0 % 322.6 672.4 Seven 191625000 76.0 % 320.2 1783.3 Nine 21950 76.8 % 329.8 2948.2 Ten 22650 76.9 % 296.6 4885.0 ABC 57150 77.0 % 542.0 7529.4 SBS 57850 77.1 % 539.5 10669.7 D44 with patch. usb device (dvb0) usbid db78:0fe9 Frequency Signal Ber Unc = 17750 76.6 % 2.3 0.0 191625000 77.0 % 235.5 83.3 21950 76.9 % 288.0 501.8 22650 76.9 % 295.1 1416.4 57150 77.0 % 523.4 3980.0 57850 77.1 % 549.9 7409.4 without patch. pcie device (dvb1) pciid db78:18ac Frequency Signal Ber Unc = 17750 71.2 % 3.1 0.0 191625000 21.7 % 645.4 246.4 21950 73.6 % 1.9 1632.0 22650 73.5 % 2.8 1632.0 57150 73.9 % 13.6 2134.6 57850 72.7 % 58.2 6393.4 with patch. pcie device (dvb1) pciid db78:18ac Frequency Signal Ber Unc = 17750 73.2 % 4.0 0.0 191625000 74.0 % 37.0 0.0 21950 73.9 % 0.0 0.0 22650 73.0 % 4.6 0.0 57150 74.2 % 76.7 193.6 57850 72.8 % 213.8 4480.3 * 2.6.31-14-generic + v4l (19c0469c02c3+ tip) Hard to say if I'm seeing an improvement. before patching - adapter0 usbid db78:0fe9 Frequency Signal Ber Unc = 17750 75.5 % 293.7 1926.4 191625000 75.9 % 363.2 2993.3 21950 76.7 % 304.5 4225.8 22650 76.9 % 223.8 6153.3 57150 77.0 % 491.7 8726.0 57850 77.1 % 558.9 11787.1 adapter0 repeat usbid db78:0fe9 (not sure what happened to UNC here..) Frequency Signal Ber Unc = 17750 75.9 % 327.9 13893.6 191625000 76.0 % 392.8 14939.0 21950 76.7 % 252.0 16052.0 22650 76.8 % 254.0 18063.1 57150 76.9 % 533.2 20644.1 57850 76.9 % 464.1 23836.8 after patching - adapter0 usbid db78:0fe9 Frequency Signal Ber Unc = 17750 76.3 % 2.5 0.0 191625000 76.8 % 227.6 119.0 21950 76.8 % 262.6 604.5 22650 76.8 % 282.7 1545.4 57150 77.0 % 486.8 3541.7 57850 77.1 % 521.5 6537.7
Trouble using OMAP3530 previewer in oneshot mode
Hi,
I'm trying to run OMAP3 ISP previewer in oneshot mode, without much success.
My goal is to put a 6MB Bayer10 image (captured on the same OMAP3 EVM)
into RAM, run previewer and get its output in RAM. I use linux-2.6.29 kernel
with ISP driver from omap3camera git tree.
For testing purposes Bayer10 image is stored into a file. My driver
allocates
a 6MB buffer using iommu_vmalloc(), application maps this buffer using
driver's mmap() method, copies input file into a buffer and signals the
driver to
start a previewer. In PREV_DONE interrupt callback the driver wakes
application which stores previewer output from buffer into a file.
The following code runs previewer in oneshot mode (error checking
removed for simplicity)
int isppreview_set_image_size(int width, int height)
{
isp_obj.module.preview_input_height = height;
isp_obj.module.preview_input_width = width;
isp_obj.module.isp_pipeline = OMAP_ISP_PREVIEW;
isppreview_try_size(isp_obj.module.preview_input_width,
isp_obj.module.preview_input_height,
isp_obj.module.preview_output_width,
isp_obj.module.preview_output_height);
isppreview_config_inlineoffset(height * 2);
isppreview_config_size(isp_obj.module.preview_input_width,
isp_obj.module.preview_input_height,
isp_obj.module.preview_output_width,
isp_obj.module.preview_output_height);
}
int oneshot(int width, int height)
{
isppreview_request();
isp_set_callback(CBK_PREV_DONE, prev_done_cbk, NULL, NULL);
isppreview_config_datapath(PRV_RAW_MEM, PREVIEW_MEM);
isppreview_set_inaddr(prev_mem_mmu);
isppreview_set_outaddr(prev_mem_mmu);
isppreview_set_image_size(width, height);
isp_enable_interrupts(0);
isppreview_enable(1);
}
The PREV_DONE interrupt arrives, application saves resulting
image into a file, but it contains junk. The input file is known to
be good. The buffer mapping is good as well.
What am I doing wrong ?
Thanks a lot for your help.
Felix.
--
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] V4L - Fix videobuf_dma_contig_user_get() getting page aligned physical address
Magnus, Thanks for the patch. For non-page aligned user space pointers I agree that a fix is needed. Don't you think the while loop in videobuf_dma_contig_user_get() also needs to be adjusted to include the last page? I think the while loop checks one page too little in the non-aligned case today. Cheers, / magnus Thanks for reviewing my patch. It had worked for non-aligned address in my testing. If I understand this code correctly, the physical address of the user page start is determined in the first loop (pages_done == 0) and additional loops are run to make sure the memory is physically contiguous. Initially the mem-size is set to number of pages aligned to page size. Assume we pass 4097 bytes as size. mem-size = PAGE_ALIGN(vb-size); = 2 Inside the loop, iteration is done for 0 to pages-1. pages_done (mem-size 12) = pages_done 2 = iterate 2 times For size of 4096, we iterate once. For size of 4095, we iterate once. So IMO the loop is already iterate one more time when we pass non-aligned address since size is aligned to include the last page. So based on this could you ack my patch so that we could ask Mauro to merge it with priority? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] Another approach to IR
On Wed, Dec 02, 2009 at 12:30:29PM -0500, Jon Smirl wrote: On Wed, Dec 2, 2009 at 12:10 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Wed, Dec 02, 2009 at 10:44:58AM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: On Tue, Dec 01, 2009 at 07:05:49PM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote: For sure we need to add an EVIOSETPROTO ioctl to allow the driver to change the protocol in runtime. Mauro, I think this kind of confuguration belongs to lirc device space, not input/evdev. This is the same as protocol selection for psmouse module: while it is normally auto-detected we have sysfs attribute to force one or another and it is tied to serio device, not input device. Dmitry, This has nothing to do with the raw interface nor with lirc. This problem happens with the evdev interface and already affects the in-kernel drivers. In this case, psmouse is not a good example. With a mouse, when a movement occurs, you'll receive some data from its port. So, a software can autodetect the protocol. The same principle can be used also with a raw pulse/space interface, where software can autodetect the protocol. Or, in certain cases, it can not. [... skipped rationale for adding a way to control protocol (with which I agree) ...] To solve this, we really need to extend evdev API to do 3 things: enumberate the supported protocols, get the current protocol(s), and select the protocol(s) that will be used by a newer table. And here we start disagreeing. My preference would be for adding this API on lirc device level (i.e. /syc/class/lirc/lircX/blah namespace), since it only applicable to IR, not to input devices in general. Once you selected proper protocol(s) and maybe instantiated several input devices then udev (by examining input device capabilities and optionally looking up at the parent device properties) would use input evdev API to load proper keymap. Because translation of driver-specific codes into standard key definitions is in the input realm. Reading these driver-specific codes from hardware is outside of input layer domain. Just as psmouse ability to specify protocol is not shoved into evdev; just as atkbd quirks (force release key list and other driver-specific options) are not in evdev either; we should not overload evdev interface with IR-specific items. I'm not against mapping those features as sysfs atributes, but they don't belong to lirc, as far as I understand. From all we've discussed, we'll create a lirc interface to allow the direct usage of raw IO. However, IR protocol is a property that is not related to raw IO mode but, instead, to evdev mode. Why would protocol relate to evdev node? Evdev does not really care what how the fact that a certain button was pressed was communicated to it. It may be deliveretd through PS/2 port, or maybe it was Bluetooth HID, or USB HID or USB boot protocol or some custom protocol, or RC-5, NEC or some custom IR protocol. It makes no difference _whatsoever_ to evdev nor any users of evdev care about protocol used by underlying hardware device to transmit the data. We might add a /sys/class/IR and add IR specific stuff there, but it seems overkill to me and will hide the fact that those parameters are part of the evdev interface. So, I would just add the IR sysfs parameters at the /sys/class/input, if the device is an IR (or create it is /sys/class/input/IR). I agree that the code to implement the IR specific sysfs parameter should be kept oustide input core, as they're specific to IR implementations. Would this work for you? I am seeing a little bit differently structured subsystem for IR at the moment. I think we should do something like this: - receivers create /sys/class/lirc devices. These devices provide API with a ring buffer (fifo) for the raw data stream coming from (and to) them. The raw interface applies only to the devices that doesn't have a hardware decoder (something between 40%-60% of the currently supported devices). 50% is quite a number I think. But if driver does not allow access to the raw stream - it will refuse binding to lirc_dev interface. - we allow registering several data interfaces/decoders that can be bound (manually or maybe automatically) to lirc devices. lirc devices may provide hints as to which interface(s) better suited for handling the data coming form particular receiver. Several interfaces may be bound to one device at a time. - one of the interfaces is interface implementing
Re: [RFC v2] Another approach to IR
On 12/2/09 12:30 PM, Jon Smirl wrote: (for each remote/substream that they can recognize). I'm assuming that, by remote, you're referring to a remote receiver (and not to the remote itself), right? If we could separate by remote transmitter that would be the best I think, but I understand that it is rarely possible? The code I posted using configfs did that. Instead of making apps IR aware it mapped the vendor/device/command triplets into standard Linux keycodes. Each remote was its own evdev device. Note, of course, that you can only do that iff each remote uses distinct triplets. A good portion of mythtv users use a universal of some sort, programmed to emulate another remote, such as the mce remote bundled with mceusb transceivers, or the imon remote bundled with most imon receivers. I do just that myself. Personally, I've always considered the driver/interface to be the receiver, not the remote. The lirc drivers operate at the receiver level, anyway, and the distinction between different remotes is made by the lirc daemon. For IR to just work the irrecord training process needs be eliminated for 90% of users. Pretty sure that's already the case. I have upwards of 20 remotes and 15 receivers. I've had to run irrecord maybe two times in five years to get any of them working. The existing lirc remote database is fairly extensive. -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] Another approach to IR
Dmitry Torokhov wrote: The raw interface applies only to the devices that doesn't have a hardware decoder (something between 40%-60% of the currently supported devices). 50% is quite a number I think. But if driver does not allow access to the raw stream - it will refuse binding to lirc_dev interface. Ok. We need to cater to the future cases as well. I don't want to redesign it in 2 years. But for devices that have only hardware decoders I suppose we can short-curcuit interfaces and have a library-like module creating input devices directly. We really need only one interface for those devices. However, protocol selection is needed, as it is associated with the scantable on those devices. a sysfs entry would solve this issue. Also, we need a better schema to cleanup the keycode table. Currently, the only way I'm aware is to run a loop from 0 to 65535 associating a scancode to KEY_UNKNOWN or to KEY_RESERVED. In the case of the cheap devices with just raw interfaces, running in-kernel decoders, while it will work if you create one interface per protocol per IR receiver, this also seems overkill. Why to do that? It sounds that it will just create additional complexity at the kernelspace and at the userspace, since now userspace programs will need to open more than one device to receive the keycodes. _Yes_!!! You open as many event devices as there are devices you are interested in receiving data from. Multiplexing devices are bad, bad, bad. Witness /dev/input/mouse and all the attempts at working around the fact that if you have a special driver for one of your devices you receive events from the same device through 2 interfaces and all kind of grab, super-grab, smart-grab schemes are born. The only device that the driver can actually see is the IR receiver. There's no way to know if there is only one physical IR sending signals to it or several different models, especially if we consider that programmable IR's can be able even to generate more than one protocol at the same time, and can emulate other IR types. You might create some artificial schema to try to deal with different IR's being received at the same IR receiver, but, IMHO, this will just add a complex abstraction layer. Also, this won't give any real gain, as either both IR's will generate the same scancodes (and you can't distinguish what IR generated that code), or the scancode is different, and you can handle it differently. (for each remote/substream that they can recognize). I'm assuming that, by remote, you're referring to a remote receiver (and not to the remote itself), right? If we could separate by remote transmitter that would be the best I think, but I understand that it is rarely possible? IMHO, the better is to use a separate interface for the IR transmitters, on the devices that support this feature. There are only a few devices I'm aware of that are able to transmit IR codes. 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
[cron job] v4l-dvb daily build 2.6.22 and up: WARNINGS, 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:Wed Dec 2 19:00:03 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13538:e0cd9a337600 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-rc8-armv5: OK linux-2.6.32-rc8-armv5-davinci: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-armv5-ixp: OK linux-2.6.32-rc8-armv5-ixp: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: OK linux-2.6.32-rc8-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK 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-rc8-i686: OK linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-rc8-m32r: OK linux-2.6.30-mips: OK linux-2.6.31-mips: OK linux-2.6.32-rc8-mips: OK linux-2.6.30-powerpc64: OK linux-2.6.31-powerpc64: OK linux-2.6.32-rc8-powerpc64: OK linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK 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-rc8-x86_64: OK spec: OK sparse (linux-2.6.31): ERRORS sparse (linux-2.6.32-rc8): 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/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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 v2] Another approach to IR
On Wed, Dec 2, 2009 at 2:33 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Dmitry Torokhov wrote: The raw interface applies only to the devices that doesn't have a hardware decoder (something between 40%-60% of the currently supported devices). 50% is quite a number I think. But if driver does not allow access to the raw stream - it will refuse binding to lirc_dev interface. Ok. We need to cater to the future cases as well. I don't want to redesign it in 2 years. But for devices that have only hardware decoders I suppose we can short-curcuit interfaces and have a library-like module creating input devices directly. We really need only one interface for those devices. However, protocol selection is needed, as it is associated with the scantable on those devices. a sysfs entry would solve this issue. Also, we need a better schema to cleanup the keycode table. Currently, the only way I'm aware is to run a loop from 0 to 65535 associating a scancode to KEY_UNKNOWN or to KEY_RESERVED. In the case of the cheap devices with just raw interfaces, running in-kernel decoders, while it will work if you create one interface per protocol per IR receiver, this also seems overkill. Why to do that? It sounds that it will just create additional complexity at the kernelspace and at the userspace, since now userspace programs will need to open more than one device to receive the keycodes. _Yes_!!! You open as many event devices as there are devices you are interested in receiving data from. Multiplexing devices are bad, bad, bad. Witness /dev/input/mouse and all the attempts at working around the fact that if you have a special driver for one of your devices you receive events from the same device through 2 interfaces and all kind of grab, super-grab, smart-grab schemes are born. The only device that the driver can actually see is the IR receiver. There's no way to know if there is only one physical IR sending signals to it or several different models, especially if we consider that programmable IR's can be able even to generate more than one protocol at the same time, and can emulate other IR types. IR devices transmit vendor/device/command triplets. They are easy to tell apart and create an evdev device corresponding to each vendor/device pair or something else along those lines. If I tell a programmable remote to send out the same commands as my Sony remote that's the same thing as owning two identical Sony remotes. I'd expect them to be indistinguishable. If you want to be able to tell your remotes apart, don't program them to emulate each other. I've published code that can split these devices apart, it's not impossible to do. 802.11 receivers have the same problem, there is one receiver and many transmitters. The networking code doesn't have problems with sorting this out and separating the streams. You might create some artificial schema to try to deal with different IR's being received at the same IR receiver, but, IMHO, this will just add a complex abstraction layer. Also, this won't give any real gain, as either both IR's will generate the same scancodes (and you can't distinguish what IR generated that code), or the scancode is different, and you can handle it differently. Reusing the keycode is fine if they on different evdev devices. A key feature is creating one evdev device for each remote. (for each remote/substream that they can recognize). I'm assuming that, by remote, you're referring to a remote receiver (and not to the remote itself), right? If we could separate by remote transmitter that would be the best I think, but I understand that it is rarely possible? IMHO, the better is to use a separate interface for the IR transmitters, on the devices that support this feature. There are only a few devices I'm aware of that are able to transmit IR codes. Cheers, Mauro. -- 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: [RFC v2] Another approach to IR
On Dec 2, 2009, at 2:33 PM, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: ... (for each remote/substream that they can recognize). I'm assuming that, by remote, you're referring to a remote receiver (and not to the remote itself), right? If we could separate by remote transmitter that would be the best I think, but I understand that it is rarely possible? IMHO, the better is to use a separate interface for the IR transmitters, on the devices that support this feature. There are only a few devices I'm aware of that are able to transmit IR codes. If I'm thinking clearly, there are only three lirc kernel drivers that support transmit, lirc_mceusb, lirc_zilog and lirc_serial. The mceusb driver was posted, so I won't rehash what it is here. The zilog driver binds to a Zilog z80 microprocessor thingy (iirc) exposed via i2c, found on many Hauppauge v4l/dvb devices (PVR-150, HVR-1600, HD-PVR, etc). The serial driver is fairly self-explanatory as well. There are also a few userspace-driven devices that do transmit, but I'm assuming they're (currently) irrelevant to this discussion. -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] Another approach to IR
On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote: On 12/2/09 12:30 PM, Jon Smirl wrote: (for each remote/substream that they can recognize). I'm assuming that, by remote, you're referring to a remote receiver (and not to the remote itself), right? If we could separate by remote transmitter that would be the best I think, but I understand that it is rarely possible? The code I posted using configfs did that. Instead of making apps IR aware it mapped the vendor/device/command triplets into standard Linux keycodes. Each remote was its own evdev device. Note, of course, that you can only do that iff each remote uses distinct triplets. A good portion of mythtv users use a universal of some sort, programmed to emulate another remote, such as the mce remote bundled with mceusb transceivers, or the imon remote bundled with most imon receivers. I do just that myself. Personally, I've always considered the driver/interface to be the receiver, not the remote. The lirc drivers operate at the receiver level, anyway, and the distinction between different remotes is made by the lirc daemon. The fact that lirc does it this way does not necessarily mean it is the most corerct way. Do you expect all bluetooth input devices be presented as a single blob just because they happen to talk to the sane receiver in yoru laptop? Do you expect your USB mouse and keyboard be merged together just because they end up being serviced by the same host controller? If not why remotes should be any different? Now I understand that if 2 remotes send completely identical signals we won't be able to separete them, but in cases when we can I think we should. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] Another approach to IR
On Wed, Dec 2, 2009 at 2:50 PM, Jon Smirl jonsm...@gmail.com wrote: On Wed, Dec 2, 2009 at 2:33 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Dmitry Torokhov wrote: The raw interface applies only to the devices that doesn't have a hardware decoder (something between 40%-60% of the currently supported devices). 50% is quite a number I think. But if driver does not allow access to the raw stream - it will refuse binding to lirc_dev interface. Ok. We need to cater to the future cases as well. I don't want to redesign it in 2 years. But for devices that have only hardware decoders I suppose we can short-curcuit interfaces and have a library-like module creating input devices directly. We really need only one interface for those devices. However, protocol selection is needed, as it is associated with the scantable on those devices. a sysfs entry would solve this issue. Also, we need a better schema to cleanup the keycode table. Currently, the only way I'm aware is to run a loop from 0 to 65535 associating a scancode to KEY_UNKNOWN or to KEY_RESERVED. In the case of the cheap devices with just raw interfaces, running in-kernel decoders, while it will work if you create one interface per protocol per IR receiver, this also seems overkill. Why to do that? It sounds that it will just create additional complexity at the kernelspace and at the userspace, since now userspace programs will need to open more than one device to receive the keycodes. _Yes_!!! You open as many event devices as there are devices you are interested in receiving data from. Multiplexing devices are bad, bad, bad. Witness /dev/input/mouse and all the attempts at working around the fact that if you have a special driver for one of your devices you receive events from the same device through 2 interfaces and all kind of grab, super-grab, smart-grab schemes are born. The only device that the driver can actually see is the IR receiver. There's no way to know if there is only one physical IR sending signals to it or several different models, especially if we consider that programmable IR's can be able even to generate more than one protocol at the same time, and can emulate other IR types. IR devices transmit vendor/device/command triplets. They are easy to tell apart and create an evdev device corresponding to each vendor/device pair or something else along those lines. I forgot about fixed function receivers - ones that only receive codes from a specific vendor/device pair and decode them in hardware. Those devices would just create a fixed entry in the configfs which would then allow a keycode mapping to be loaded. Or a parallel scheme for setkeys IOCTL. These device can only receive from a single remote. If I tell a programmable remote to send out the same commands as my Sony remote that's the same thing as owning two identical Sony remotes. I'd expect them to be indistinguishable. If you want to be able to tell your remotes apart, don't program them to emulate each other. I've published code that can split these devices apart, it's not impossible to do. 802.11 receivers have the same problem, there is one receiver and many transmitters. The networking code doesn't have problems with sorting this out and separating the streams. You might create some artificial schema to try to deal with different IR's being received at the same IR receiver, but, IMHO, this will just add a complex abstraction layer. Also, this won't give any real gain, as either both IR's will generate the same scancodes (and you can't distinguish what IR generated that code), or the scancode is different, and you can handle it differently. Reusing the keycode is fine if they on different evdev devices. A key feature is creating one evdev device for each remote. (for each remote/substream that they can recognize). I'm assuming that, by remote, you're referring to a remote receiver (and not to the remote itself), right? If we could separate by remote transmitter that would be the best I think, but I understand that it is rarely possible? IMHO, the better is to use a separate interface for the IR transmitters, on the devices that support this feature. There are only a few devices I'm aware of that are able to transmit IR codes. Cheers, Mauro. -- Jon Smirl jonsm...@gmail.com -- 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: [RFC v2] Another approach to IR
On Wed, Dec 02, 2009 at 05:33:34PM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: The raw interface applies only to the devices that doesn't have a hardware decoder (something between 40%-60% of the currently supported devices). 50% is quite a number I think. But if driver does not allow access to the raw stream - it will refuse binding to lirc_dev interface. Ok. We need to cater to the future cases as well. I don't want to redesign it in 2 years. But for devices that have only hardware decoders I suppose we can short-curcuit interfaces and have a library-like module creating input devices directly. We really need only one interface for those devices. However, protocol selection is needed, as it is associated with the scantable on those devices. a sysfs entry would solve this issue. Also, we need a better schema to cleanup the keycode table. Currently, the only way I'm aware is to run a loop from 0 to 65535 associating a scancode to KEY_UNKNOWN or to KEY_RESERVED. I guess we could entertain EVIOCSKMAPFLUSH or something... In the case of the cheap devices with just raw interfaces, running in-kernel decoders, while it will work if you create one interface per protocol per IR receiver, this also seems overkill. Why to do that? It sounds that it will just create additional complexity at the kernelspace and at the userspace, since now userspace programs will need to open more than one device to receive the keycodes. _Yes_!!! You open as many event devices as there are devices you are interested in receiving data from. Multiplexing devices are bad, bad, bad. Witness /dev/input/mouse and all the attempts at working around the fact that if you have a special driver for one of your devices you receive events from the same device through 2 interfaces and all kind of grab, super-grab, smart-grab schemes are born. The only device that the driver can actually see is the IR receiver. There's no way to know if there is only one physical IR sending signals to it or several different models, especially if we consider that programmable IR's can be able even to generate more than one protocol at the same time, and can emulate other IR types. You might create some artificial schema to try to deal with different IR's being received at the same IR receiver, but, IMHO, this will just add a complex abstraction layer. Also, this won't give any real gain, as either both IR's will generate the same scancodes (and you can't distinguish what IR generated that code), or the scancode is different, and you can handle it differently. No it will. User will have _an option_ of assigning a particular remote to a particular application. Whether he or she will chose to entertain this option is up to that user. (for each remote/substream that they can recognize). I'm assuming that, by remote, you're referring to a remote receiver (and not to the remote itself), right? If we could separate by remote transmitter that would be the best I think, but I understand that it is rarely possible? IMHO, the better is to use a separate interface for the IR transmitters, on the devices that support this feature. There are only a few devices I'm aware of that are able to transmit IR codes. -ENOOPINION at the moment. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] Another approach to IR
On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote: On 12/2/09 12:30 PM, Jon Smirl wrote: (for each remote/substream that they can recognize). I'm assuming that, by remote, you're referring to a remote receiver (and not to the remote itself), right? If we could separate by remote transmitter that would be the best I think, but I understand that it is rarely possible? The code I posted using configfs did that. Instead of making apps IR aware it mapped the vendor/device/command triplets into standard Linux keycodes. Each remote was its own evdev device. Note, of course, that you can only do that iff each remote uses distinct triplets. A good portion of mythtv users use a universal of some sort, programmed to emulate another remote, such as the mce remote bundled with mceusb transceivers, or the imon remote bundled with most imon receivers. I do just that myself. Personally, I've always considered the driver/interface to be the receiver, not the remote. The lirc drivers operate at the receiver level, anyway, and the distinction between different remotes is made by the lirc daemon. The fact that lirc does it this way does not necessarily mean it is the most corerct way. No, I know that, I'm just saying that's how I've always looked at it, and that's how lirc does it right now, not that it must be that way. Do you expect all bluetooth input devices be presented as a single blob just because they happen to talk to the sane receiver in yoru laptop? Do you expect your USB mouse and keyboard be merged together just because they end up being serviced by the same host controller? If not why remotes should be any different? A bluetooth remote has a specific device ID that the receiver has to pair with. Your usb mouse and keyboard each have specific device IDs. A usb IR *receiver* has a specific device ID, the remotes do not. So there's the major difference from your examples. Now I understand that if 2 remotes send completely identical signals we won't be able to separete them, but in cases when we can I think we should. I don't have a problem with that, if its a truly desired feature. But for the most part, I don't see the point. Generally, you go from having multiple remotes, one per device (where device is your TV, amplifier, set top box, htpc, etc), to having a single universal remote that controls all of those devices. But for each device (IR receiver), *one* IR command set. The desire to use multiple distinct remotes with a single IR receiver doesn't make sense to me. Perhaps I'm just not creative enough in my use of IR. :) -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] Another approach to IR
On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote: On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote: On 12/2/09 12:30 PM, Jon Smirl wrote: (for each remote/substream that they can recognize). I'm assuming that, by remote, you're referring to a remote receiver (and not to the remote itself), right? If we could separate by remote transmitter that would be the best I think, but I understand that it is rarely possible? The code I posted using configfs did that. Instead of making apps IR aware it mapped the vendor/device/command triplets into standard Linux keycodes. Each remote was its own evdev device. Note, of course, that you can only do that iff each remote uses distinct triplets. A good portion of mythtv users use a universal of some sort, programmed to emulate another remote, such as the mce remote bundled with mceusb transceivers, or the imon remote bundled with most imon receivers. I do just that myself. Personally, I've always considered the driver/interface to be the receiver, not the remote. The lirc drivers operate at the receiver level, anyway, and the distinction between different remotes is made by the lirc daemon. The fact that lirc does it this way does not necessarily mean it is the most corerct way. No, I know that, I'm just saying that's how I've always looked at it, and that's how lirc does it right now, not that it must be that way. Do you expect all bluetooth input devices be presented as a single blob just because they happen to talk to the sane receiver in yoru laptop? Do you expect your USB mouse and keyboard be merged together just because they end up being serviced by the same host controller? If not why remotes should be any different? A bluetooth remote has a specific device ID that the receiver has to pair with. Your usb mouse and keyboard each have specific device IDs. A usb IR *receiver* has a specific device ID, the remotes do not. So there's the major difference from your examples. Not exactly... I can have 2 identical USB keyboadrs form the same manufacturer and they will still be treated separately. BT has session ID to help distinguish between devices. Now I understand that if 2 remotes send completely identical signals we won't be able to separete them, but in cases when we can I think we should. I don't have a problem with that, if its a truly desired feature. But for the most part, I don't see the point. Generally, you go from having multiple remotes, one per device (where device is your TV, amplifier, set top box, htpc, etc), to having a single universal remote that controls all of those devices. But for each device (IR receiver), *one* IR command set. The desire to use multiple distinct remotes with a single IR receiver doesn't make sense to me. Perhaps I'm just not creative enough in my use of IR. :) Didn't Jon posted his example whith programmable remote pretending to be several separate remotes (depending on the mode of operation) so that several devices/applications can be controlled without interfering with each other? -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] Another approach to IR
Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote: On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote: On 12/2/09 12:30 PM, Jon Smirl wrote: (for each remote/substream that they can recognize). I'm assuming that, by remote, you're referring to a remote receiver (and not to the remote itself), right? If we could separate by remote transmitter that would be the best I think, but I understand that it is rarely possible? The code I posted using configfs did that. Instead of making apps IR aware it mapped the vendor/device/command triplets into standard Linux keycodes. Each remote was its own evdev device. Note, of course, that you can only do that iff each remote uses distinct triplets. A good portion of mythtv users use a universal of some sort, programmed to emulate another remote, such as the mce remote bundled with mceusb transceivers, or the imon remote bundled with most imon receivers. I do just that myself. Personally, I've always considered the driver/interface to be the receiver, not the remote. The lirc drivers operate at the receiver level, anyway, and the distinction between different remotes is made by the lirc daemon. The fact that lirc does it this way does not necessarily mean it is the most corerct way. No, I know that, I'm just saying that's how I've always looked at it, and that's how lirc does it right now, not that it must be that way. Do you expect all bluetooth input devices be presented as a single blob just because they happen to talk to the sane receiver in yoru laptop? Do you expect your USB mouse and keyboard be merged together just because they end up being serviced by the same host controller? If not why remotes should be any different? A bluetooth remote has a specific device ID that the receiver has to pair with. Your usb mouse and keyboard each have specific device IDs. A usb IR *receiver* has a specific device ID, the remotes do not. So there's the major difference from your examples. Not exactly... I can have 2 identical USB keyboadrs form the same manufacturer and they will still be treated separately. BT has session ID to help distinguish between devices. Now I understand that if 2 remotes send completely identical signals we won't be able to separete them, but in cases when we can I think we should. I don't have a problem with that, if its a truly desired feature. But for the most part, I don't see the point. Generally, you go from having multiple remotes, one per device (where device is your TV, amplifier, set top box, htpc, etc), to having a single universal remote that controls all of those devices. But for each device (IR receiver), *one* IR command set. The desire to use multiple distinct remotes with a single IR receiver doesn't make sense to me. Perhaps I'm just not creative enough in my use of IR. :) Didn't Jon posted his example whith programmable remote pretending to be several separate remotes (depending on the mode of operation) so that several devices/applications can be controlled without interfering with each other? From what I understood, he is using the same physical remote, but creating different IR groups of keys on it, each group meant to be used by a different application. For such usage, some software will need to filter the scancode group and send them only for a certain application. This can be done easily by using lirc, purely in userspace. Another alternative (that will also work for multimedia keys on a keyboard) is to add a filtering subsystem at evdev that will send certain events for just certain PID's. Of course, it is feasible to do it in kernel, but, IMHO, it would be better to let userspace to take care of this. 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 v2] Another approach to IR
On Dec 2, 2009, at 3:14 PM, Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote: On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote: On 12/2/09 12:30 PM, Jon Smirl wrote: (for each remote/substream that they can recognize). I'm assuming that, by remote, you're referring to a remote receiver (and not to the remote itself), right? If we could separate by remote transmitter that would be the best I think, but I understand that it is rarely possible? The code I posted using configfs did that. Instead of making apps IR aware it mapped the vendor/device/command triplets into standard Linux keycodes. Each remote was its own evdev device. Note, of course, that you can only do that iff each remote uses distinct triplets. A good portion of mythtv users use a universal of some sort, programmed to emulate another remote, such as the mce remote bundled with mceusb transceivers, or the imon remote bundled with most imon receivers. I do just that myself. Personally, I've always considered the driver/interface to be the receiver, not the remote. The lirc drivers operate at the receiver level, anyway, and the distinction between different remotes is made by the lirc daemon. The fact that lirc does it this way does not necessarily mean it is the most corerct way. No, I know that, I'm just saying that's how I've always looked at it, and that's how lirc does it right now, not that it must be that way. Do you expect all bluetooth input devices be presented as a single blob just because they happen to talk to the sane receiver in yoru laptop? Do you expect your USB mouse and keyboard be merged together just because they end up being serviced by the same host controller? If not why remotes should be any different? A bluetooth remote has a specific device ID that the receiver has to pair with. Your usb mouse and keyboard each have specific device IDs. A usb IR *receiver* has a specific device ID, the remotes do not. So there's the major difference from your examples. Not exactly... I can have 2 identical USB keyboadrs form the same manufacturer and they will still be treated separately. BT has session ID to help distinguish between devices. Semantics. :) My main point is that each of these devices has device ID that can be determined without having to first do some protocol analysis and table lookups to figure out which device some random IR input is actually coming from. Now I understand that if 2 remotes send completely identical signals we won't be able to separete them, but in cases when we can I think we should. I don't have a problem with that, if its a truly desired feature. But for the most part, I don't see the point. Generally, you go from having multiple remotes, one per device (where device is your TV, amplifier, set top box, htpc, etc), to having a single universal remote that controls all of those devices. But for each device (IR receiver), *one* IR command set. The desire to use multiple distinct remotes with a single IR receiver doesn't make sense to me. Perhaps I'm just not creative enough in my use of IR. :) Didn't Jon posted his example whith programmable remote pretending to be several separate remotes (depending on the mode of operation) so that several devices/applications can be controlled without interfering with each other? Yes. But that's an atypical usage, in my experience, and as Mauro said, something that can be done trivially in userspace (lirc can do this today, even for the same remote and mode of operation, on a per-key basis if you want). If it doesn't add too much complexity and people will actually use it, I don't have a problem with implementing one input device per distinct remote, but I doubt many people would use that functionality. -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] Another approach to IR
On Wed, Dec 02, 2009 at 03:42:13PM -0500, Jarod Wilson wrote: On Dec 2, 2009, at 3:14 PM, Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote: On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote: On 12/2/09 12:30 PM, Jon Smirl wrote: (for each remote/substream that they can recognize). I'm assuming that, by remote, you're referring to a remote receiver (and not to the remote itself), right? If we could separate by remote transmitter that would be the best I think, but I understand that it is rarely possible? The code I posted using configfs did that. Instead of making apps IR aware it mapped the vendor/device/command triplets into standard Linux keycodes. Each remote was its own evdev device. Note, of course, that you can only do that iff each remote uses distinct triplets. A good portion of mythtv users use a universal of some sort, programmed to emulate another remote, such as the mce remote bundled with mceusb transceivers, or the imon remote bundled with most imon receivers. I do just that myself. Personally, I've always considered the driver/interface to be the receiver, not the remote. The lirc drivers operate at the receiver level, anyway, and the distinction between different remotes is made by the lirc daemon. The fact that lirc does it this way does not necessarily mean it is the most corerct way. No, I know that, I'm just saying that's how I've always looked at it, and that's how lirc does it right now, not that it must be that way. Do you expect all bluetooth input devices be presented as a single blob just because they happen to talk to the sane receiver in yoru laptop? Do you expect your USB mouse and keyboard be merged together just because they end up being serviced by the same host controller? If not why remotes should be any different? A bluetooth remote has a specific device ID that the receiver has to pair with. Your usb mouse and keyboard each have specific device IDs. A usb IR *receiver* has a specific device ID, the remotes do not. So there's the major difference from your examples. Not exactly... I can have 2 identical USB keyboadrs form the same manufacturer and they will still be treated separately. BT has session ID to help distinguish between devices. Semantics. :) My main point is that each of these devices has device ID that can be determined without having to first do some protocol analysis and table lookups to figure out which device some random IR input is actually coming from. Heh, right back at ya ;) The fact that you need to do some more work to separate 2 physical devices does not mean it should not be done. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] Another approach to IR
Jon Smirl wrote: IR devices transmit vendor/device/command triplets. They are easy to tell apart and create an evdev device corresponding to each vendor/device pair or something else along those lines. What they transmit depend on the used protocol. With NEC and RC5 (currently, the most common protocols), they transmit only address (TV, VCR, SAT) and command. If you have two IR's that not fully follow RC5 standard, they may use distinct addresses. So, if you're lucky enough, you'll be able to guess the IR vendor, based on the 8 bit address code. I think that you can get the vendor only with RC6 IR's on some modes. In the case of RC6, as pointed by Andy, there are some patents envolved, meaning that we probably will need to decode it on userspace, except if someone can get the proper patent rights for its used on Linux. 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 v2] Another approach to IR
On Wed, Dec 02, 2009 at 06:23:51PM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote: On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote: Now I understand that if 2 remotes send completely identical signals we won't be able to separete them, but in cases when we can I think we should. I don't have a problem with that, if its a truly desired feature. But for the most part, I don't see the point. Generally, you go from having multiple remotes, one per device (where device is your TV, amplifier, set top box, htpc, etc), to having a single universal remote that controls all of those devices. But for each device (IR receiver), *one* IR command set. The desire to use multiple distinct remotes with a single IR receiver doesn't make sense to me. Perhaps I'm just not creative enough in my use of IR. :) Didn't Jon posted his example whith programmable remote pretending to be several separate remotes (depending on the mode of operation) so that several devices/applications can be controlled without interfering with each other? From what I understood, he is using the same physical remote, but creating different IR groups of keys on it, each group meant to be used by a different application. For such usage, some software will need to filter the scancode group and send them only for a certain application. This can be done easily by using lirc, purely in userspace. Another alternative (that will also work for multimedia keys on a keyboard) is to add a filtering subsystem at evdev that will send certain events for just certain PID's. They are the same key events (Lets's say KEY_PLAY) but one is supposed to affect CD player while another DVD player application. Evdev will not be able to distinguish them but if we had 2 separate devices then applications could read from the one thet user assigned to them. However even subscription is something that is desirable to have ouside of IRC handling topic (so that supporting applications need not be woken up by events they are not interested in - example mixer application is interested in KEY_VOLUMEUP, KEY_VOLUMEDOWN and KEY_MUTE but not any other key that may be emitted by a keyboard). -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] Another approach to IR
Jon Smirl wrote: Some major use cases: using IR as a keyboard replacement, controlling X and apps with it in via mouse and keyboard emulation. using IR to control a headless embedded device possibly running multiple apps - like audio and home automation (my app) IR during boot when it is the only input device the box has. multifunction remote controlling several apps using several different remotes to control a single app I think you reasonably described the major usecases. If everyone hates configfs the same mapping can be done via the set keys IOCTL and making changes to the user space apps like loadkeys. It is not the hate of configfs per se, but rather concern that configfs takes too much resources and is not normally enabled. It adds about 35K on 64b x86. 30K on 32b powerpc. If it gets turned on by default other subsystems might start using it too. I work on an embedded system. These arguments about non-swapable vs swapable are pointless. Embedded systems don't have swap devices. Of course config can be eliminated by modifying the setkeys IOCTL and user space tools. It will require some more mods to input to allow multiple maps monitoring the input stream and splitting them onto multiple evdev devices. This is an equally valid way of building the maps. The code I posted is just demo code. It is clearly not in shape to be merged. Its purpose was to spark a design discussion around creating a good long-term architecture for IR. Unfortunately, afaik, most distros don't enable configfs yet. I have to manually compile my kernel when I need some useful stuff there. I agree with Dmitry: IR is probably not enough to have this enabled by default on distros. I prefer a more traditional approach like ioctls (and/or sysfs) instead of configfs. 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 v2] Another approach to IR
On Dec 2, 2009, at 3:48 PM, Dmitry Torokhov wrote: ... Personally, I've always considered the driver/interface to be the receiver, not the remote. The lirc drivers operate at the receiver level, anyway, and the distinction between different remotes is made by the lirc daemon. The fact that lirc does it this way does not necessarily mean it is the most corerct way. No, I know that, I'm just saying that's how I've always looked at it, and that's how lirc does it right now, not that it must be that way. Do you expect all bluetooth input devices be presented as a single blob just because they happen to talk to the sane receiver in yoru laptop? Do you expect your USB mouse and keyboard be merged together just because they end up being serviced by the same host controller? If not why remotes should be any different? A bluetooth remote has a specific device ID that the receiver has to pair with. Your usb mouse and keyboard each have specific device IDs. A usb IR *receiver* has a specific device ID, the remotes do not. So there's the major difference from your examples. Not exactly... I can have 2 identical USB keyboadrs form the same manufacturer and they will still be treated separately. BT has session ID to help distinguish between devices. Semantics. :) My main point is that each of these devices has device ID that can be determined without having to first do some protocol analysis and table lookups to figure out which device some random IR input is actually coming from. Heh, right back at ya ;) The fact that you need to do some more work to separate 2 physical devices does not mean it should not be done. No, but it means added complexity inside the kernel. I'm questioning whether the added complexity is worth it, when I doubt the vast majority of users would take advantage of it, and it can already be done in userspace. Although... Damn. The userspace approach would only work if the device were passing raw IR to userspace, so in the in-kernel decoding case, yeah, I guess you'd need separate input devices for each remote to use them independently. Meh. Doubt I'd ever use it, but I guess I'll concede that it makes some sense to do the extra work. -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] Another approach to IR
On Wed, 2 Dec 2009, Jarod Wilson wrote: My main point is that each of these devices has device ID that can be determined without having to first do some protocol analysis and table lookups to figure out which device some random IR input is actually coming from. Heh, right back at ya ;) The fact that you need to do some more work to separate 2 physical devices does not mean it should not be done. No, but it means added complexity inside the kernel. I'm questioning whether the added complexity is worth it, when I doubt the vast majority of users would take advantage of it, and it can already be done in userspace. Although... Damn. The userspace approach would only work if the device were passing raw IR to userspace, so in the in-kernel decoding case, yeah, I guess you'd need separate input devices for each remote to use them independently. Meh. Doubt I'd ever use it, but I guess I'll concede that it makes some sense to do the extra work. You just need to send a tuple that contrains the keycode plus some kind of id for the remote it came from. That's what I did for lirc, it decodes the sparc/mark into a remote id and key code tuple. It's certainly a common thing to want. Anyone who has existing remotes and components that use them would want it. You don't want your computer turning off when you push the power button on the DVD player's remote, do you? Each host connected to a network interface doesn't get its own device. -- 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 v2] Another approach to IR
Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 06:23:51PM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote: On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote: Now I understand that if 2 remotes send completely identical signals we won't be able to separete them, but in cases when we can I think we should. I don't have a problem with that, if its a truly desired feature. But for the most part, I don't see the point. Generally, you go from having multiple remotes, one per device (where device is your TV, amplifier, set top box, htpc, etc), to having a single universal remote that controls all of those devices. But for each device (IR receiver), *one* IR command set. The desire to use multiple distinct remotes with a single IR receiver doesn't make sense to me. Perhaps I'm just not creative enough in my use of IR. :) Didn't Jon posted his example whith programmable remote pretending to be several separate remotes (depending on the mode of operation) so that several devices/applications can be controlled without interfering with each other? From what I understood, he is using the same physical remote, but creating different IR groups of keys on it, each group meant to be used by a different application. For such usage, some software will need to filter the scancode group and send them only for a certain application. This can be done easily by using lirc, purely in userspace. Another alternative (that will also work for multimedia keys on a keyboard) is to add a filtering subsystem at evdev that will send certain events for just certain PID's. They are the same key events (Lets's say KEY_PLAY) but one is supposed to affect CD player while another DVD player application. Evdev will not be able to distinguish them but if we had 2 separate devices then applications could read from the one thet user assigned to them. This is clear, but the point is that the two distinguish scancodes can (and, in practice, will) be generated by the same IR. For example, my Satellite IR produces two different sets of codes. if you press SAT, all keys you press after that will have the sat address. If you press TV, they'll get a different address. So, the needed feature is not to really distinguish two different IR's, but to allow to create groups of scancodes that will be directed to a distinct interface. I won't object about such interface, but the default should be to have just one interface and having all conversion applied to that interface. Maybe we can have a separate module for IR evdev filtering to fulfill this need. Basically, such module will get the events from one input interface and create an arbitrary number of evdev devices, and will apply different scancode-keycode tables for each different interfaces. I don't see why to limit the input interface to be IR. It can eventually be any input interface (bluetooth, keyboard, PS/3 control, Wii control, ...). 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 v2] Another approach to IR
On Dec 2, 2009, at 4:12 PM, Trent Piepho wrote: On Wed, 2 Dec 2009, Jarod Wilson wrote: My main point is that each of these devices has device ID that can be determined without having to first do some protocol analysis and table lookups to figure out which device some random IR input is actually coming from. Heh, right back at ya ;) The fact that you need to do some more work to separate 2 physical devices does not mean it should not be done. No, but it means added complexity inside the kernel. I'm questioning whether the added complexity is worth it, when I doubt the vast majority of users would take advantage of it, and it can already be done in userspace. Although... Damn. The userspace approach would only work if the device were passing raw IR to userspace, so in the in-kernel decoding case, yeah, I guess you'd need separate input devices for each remote to use them independently. Meh. Doubt I'd ever use it, but I guess I'll concede that it makes some sense to do the extra work. You just need to send a tuple that contrains the keycode plus some kind of id for the remote it came from. That's what I did for lirc, it decodes the sparc/mark into a remote id and key code tuple. It's certainly a common thing to want. Anyone who has existing remotes and components that use them would want it. What for, exactly? You don't want your computer turning off when you push the power button on the DVD player's remote, do you? No, I don't. Perhaps we should clarify something here. Are we intending to auto-create a new input device for every IR command set we see arrive at the IR receiver? I've been assuming we're not going to willy-nilly just auto-create a new device for every IR signal we happen to catch passing by. The receiver should only be passing along input events for the codeset/remote I've told it to listen for (which by default, is the codes for the receiver's bundled remote). Otherwise, yeah, I'm going to wind up with my htpc powering off when I hit the button on my harmony remote that is supposed to turn off my tv and amp. -- 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
[PATCH - v1] V4L - Digital Video Timings API documentation
From: Muralidharan Karicheri m-kariche...@ti.com
This patch updates the v4l2-dvb documentation for the new video timings API
added.
Also updated the document based on comments from Hans Verkuil
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
diff -uNr
v4l-dvb-e0cd9a337600_master/linux/Documentation/DocBook/v4l/common.xml
v4l-dvb-patch/linux/Documentation/DocBook/v4l/common.xml
--- v4l-dvb-e0cd9a337600_master/linux/Documentation/DocBook/v4l/common.xml
2009-12-01 17:02:04.0 -0500
+++ v4l-dvb-patch/linux/Documentation/DocBook/v4l/common.xml2009-12-02
17:16:24.0 -0500
@@ -716,6 +716,41 @@
}
/programlisting
/example
+ section id=dv-timings
+ titleDigital Video (DV) Timings/title
+ para
+ The video standards discussed so far has been dealing with Analog TV
and the
+corresponding video timings. Today there are many more different hardware
interfaces
+such as High Definition TV interfaces (HDMI), VGA, DVI connectors etc., that
carry
+video signals and there is a need to extend the API to select the video timings
+ for these interfaces. Since it is not possible to extend the v4l2-std-id due
to
+the limited bits available, a new set of IOCTLs are added to set/get video
timings at
+the input and output: /paraitemizedlist
+ listitem
+ para DV Presets: Digital Video (DV) presets. These are IDs
representing a
+video timing at the input/output. Presets are pre-defined timings implemented
+by the hardware according to video standards. A __u32 data type is used to
represent
+ a preset unlike the bit mask that is used in v4l2-std-id; allowing future
extensions
+ to support many different presets as needed./para
+ /listitem
+ listitem
+ para Custom DV Timings: This will allow applications to define more
detailed
+custom video timings at the interface. This includes parameters such as width,
height,
+ polarities, frontporch, backporch etc.
+ /para
+ /listitem
+ /itemizedlist
+ para To enumerate and query the attributes of DV presets supported by
a device,
+ applications use the VIDIOC-ENUM-DV-PRESETS; ioctl. To get the current DV
preset,
+ application use the VIDIOC-G-DV-PRESET; ioctl and to set a preset it uses
the
+ VIDIOC-S-DV-PRESET; ioctl./para
+ para To set a Custom DV timings at the device, applications use the
+ VIDIOC-S-DV-TIMINGS; ioctl and to get current Custom DV timings, it uses the
+ VIDIOC-G-DV-TIMINGS; ioctl./para
+ para Applications can make use of the xref
linkend=input-capabilities / and
+xref linkend=output-capabilities/ flags to decide what ioctls are
available to set the
+video timings for the device./para
+ /section
/section
sub-controls;
diff -uNr v4l-dvb-e0cd9a337600_master/linux/Documentation/DocBook/v4l/v4l2.xml
v4l-dvb-patch/linux/Documentation/DocBook/v4l/v4l2.xml
--- v4l-dvb-e0cd9a337600_master/linux/Documentation/DocBook/v4l/v4l2.xml
2009-12-01 17:02:04.0 -0500
+++ v4l-dvb-patch/linux/Documentation/DocBook/v4l/v4l2.xml 2009-12-02
17:16:50.0 -0500
@@ -416,6 +416,10 @@
sub-enum-frameintervals;
sub-enuminput;
sub-enumoutput;
+sub-enum-dv-presets;
+sub-g-dv-preset;
+sub-query-dv-preset;
+sub-g-dv-timings;
sub-enumstd;
sub-g-audio;
sub-g-audioout;
diff -uNr
v4l-dvb-e0cd9a337600_master/linux/Documentation/DocBook/v4l/videodev2.h.xml
v4l-dvb-patch/linux/Documentation/DocBook/v4l/videodev2.h.xml
--- v4l-dvb-e0cd9a337600_master/linux/Documentation/DocBook/v4l/videodev2.h.xml
2009-12-01 17:02:04.0 -0500
+++ v4l-dvb-patch/linux/Documentation/DocBook/v4l/videodev2.h.xml
2009-12-02 17:44:24.0 -0500
@@ -734,6 +734,99 @@
};
/*
+ * V I D E O T I M I N G S D V P R E S E T
+ */
+struct link linkend=v4l2-dv-presetv4l2_dv_preset/link {
+__u32 preset;
+__u32 reserved[4];
+};
+
+/*
+ * D V P R E S E T S E N U M E R A T I O N
+ */
+struct link linkend=v4l2-dv-enum-presetv4l2_dv_enum_preset/link {
+__u32 index;
+__u32 preset;
+__u8name[32]; /* Name of the preset timing */
+__u32 width;
+__u32 height;
+__u32 reserved[4];
+};
+
+/*
+ * D V P R E S E T V A L U E S
+ */
+#define V4L2_DV_INVALID 0
+#define V4L2_DV_480P59_94 1 /* BT.1362 */
+#define V4L2_DV_576P50 2 /* BT.1362 */
+#define V4L2_DV_720P24 3 /* SMPTE 296M */
+#define V4L2_DV_720P25 4 /* SMPTE 296M */
+#define V4L2_DV_720P30 5 /* SMPTE 296M */
+#define V4L2_DV_720P50 6 /* SMPTE 296M */
+#define V4L2_DV_720P59_94 7 /* SMPTE 274M */
+#define V4L2_DV_720P60 8 /* SMPTE 274M/296M */
+#define V4L2_DV_1080I29_97 9 /* BT.1120/ SMPTE 274M */
+#define
FW: [PATCH - v1] V4L - Digital Video Timings API documentation
Hans,
I have updated the API documentation based on your comments and the updated
patch is sent to the list. So could you please send a pull request to Mauro for
the video timing API patch along with this documentation patch? If there are
any minor issues, I would prefer to fix it by another patch than re-working
this again.
Regards,
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Wednesday, December 02, 2009 5:56 PM
To: linux-media@vger.kernel.org; hverk...@xs4all.nl
Cc: davinci-linux-open-sou...@linux.davincidsp.com; Karicheri, Muralidharan
Subject: [PATCH - v1] V4L - Digital Video Timings API documentation
From: Muralidharan Karicheri m-kariche...@ti.com
This patch updates the v4l2-dvb documentation for the new video timings API
added.
Also updated the document based on comments from Hans Verkuil
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
diff -uNr v4l-dvb-
e0cd9a337600_master/linux/Documentation/DocBook/v4l/common.xml v4l-dvb-
patch/linux/Documentation/DocBook/v4l/common.xml
--- v4l-dvb-e0cd9a337600_master/linux/Documentation/DocBook/v4l/common.xml
2009-12-01 17:02:04.0 -0500
+++ v4l-dvb-patch/linux/Documentation/DocBook/v4l/common.xml 2009-12-
02 17:16:24.0 -0500
@@ -716,6 +716,41 @@
}
/programlisting
/example
+ section id=dv-timings
+ titleDigital Video (DV) Timings/title
+ para
+ The video standards discussed so far has been dealing with Analog TV
and the
+corresponding video timings. Today there are many more different hardware
interfaces
+such as High Definition TV interfaces (HDMI), VGA, DVI connectors etc.,
that carry
+video signals and there is a need to extend the API to select the video
timings
+ for these interfaces. Since it is not possible to extend the v4l2-std-id
due to
+the limited bits available, a new set of IOCTLs are added to set/get video
timings at
+the input and output: /paraitemizedlist
+ listitem
+ para DV Presets: Digital Video (DV) presets. These are IDs
representing a
+video timing at the input/output. Presets are pre-defined timings
implemented
+by the hardware according to video standards. A __u32 data type is used to
represent
+ a preset unlike the bit mask that is used in v4l2-std-id; allowing
future extensions
+ to support many different presets as needed./para
+ /listitem
+ listitem
+ para Custom DV Timings: This will allow applications to define more
detailed
+custom video timings at the interface. This includes parameters such as
width, height,
+ polarities, frontporch, backporch etc.
+ /para
+ /listitem
+ /itemizedlist
+ para To enumerate and query the attributes of DV presets supported
by a device,
+ applications use the VIDIOC-ENUM-DV-PRESETS; ioctl. To get the current
DV preset,
+ application use the VIDIOC-G-DV-PRESET; ioctl and to set a preset it
uses the
+ VIDIOC-S-DV-PRESET; ioctl./para
+ para To set a Custom DV timings at the device, applications use the
+ VIDIOC-S-DV-TIMINGS; ioctl and to get current Custom DV timings, it uses
the
+ VIDIOC-G-DV-TIMINGS; ioctl./para
+ para Applications can make use of the xref linkend=input-
capabilities / and
+xref linkend=output-capabilities/ flags to decide what ioctls are
available to set the
+video timings for the device./para
+ /section
/section
sub-controls;
diff -uNr v4l-dvb-
e0cd9a337600_master/linux/Documentation/DocBook/v4l/v4l2.xml v4l-dvb-
patch/linux/Documentation/DocBook/v4l/v4l2.xml
--- v4l-dvb-e0cd9a337600_master/linux/Documentation/DocBook/v4l/v4l2.xml
2009-12-01 17:02:04.0 -0500
+++ v4l-dvb-patch/linux/Documentation/DocBook/v4l/v4l2.xml 2009-12-02
17:16:50.0 -0500
@@ -416,6 +416,10 @@
sub-enum-frameintervals;
sub-enuminput;
sub-enumoutput;
+sub-enum-dv-presets;
+sub-g-dv-preset;
+sub-query-dv-preset;
+sub-g-dv-timings;
sub-enumstd;
sub-g-audio;
sub-g-audioout;
diff -uNr v4l-dvb-
e0cd9a337600_master/linux/Documentation/DocBook/v4l/videodev2.h.xml v4l-
dvb-patch/linux/Documentation/DocBook/v4l/videodev2.h.xml
--- v4l-dvb-
e0cd9a337600_master/linux/Documentation/DocBook/v4l/videodev2.h.xml
2009-12-01 17:02:04.0 -0500
+++ v4l-dvb-patch/linux/Documentation/DocBook/v4l/videodev2.h.xml 2009-12-
02 17:44:24.0 -0500
@@ -734,6 +734,99 @@
};
/*
+ * V I D E O T I M I N G S D V P R E S E T
+ */
+struct link linkend=v4l2-dv-presetv4l2_dv_preset/link {
+__u32 preset;
+__u32 reserved[4];
+};
+
+/*
+ * D V P R E S E T S E N U M E R A T I O N
+ */
+struct link linkend=v4l2-dv-enum-presetv4l2_dv_enum_preset/link {
+__u32 index;
+__u32 preset;
+__u8name[32]; /* Name of the preset timing */
+__u32
Re: af9015: tuner id:179 not supported, please report!
On Wed, Dec 2, 2009 at 5:06 PM, Bert Massop bert.mas...@gmail.com wrote: Jan Sundman jan.sundman at aland.net writes: Hi, I just received a usb DVB-T card and have been trying to get it to work under Ubuntu 9.10, but to no avail. dmesg shows the following when plugging in the card: [ 35.280024] usb 2-1: new high speed USB device using ehci_hcd and address 4 [ 35.435978] usb 2-1: configuration #1 chosen from 1 choice [ 35.450176] af9015: tuner id:179 not supported, please report! [ 35.452891] Afatech DVB-T 2: Fixing fullspeed to highspeed interval: 10 - 7 [ 35.453097] input: Afatech DVB-T 2 as /devices/pci:00/:00:13.2/usb2/2-1/2-1:1.1/input/input8 [ 35.453141] generic-usb 0003:15A4:9016.0005: input,hidraw3: USB HID v1.01 Keyboard [Afatech DVB-T 2] on usb-:00:13.2-1/input1 lsusb shows: Bus 002 Device 005: ID 15a4:9016 and finally lsmod | grep dvb dvb_usb_af9015 37152 0 dvb_usb 22892 1 dvb_usb_af9015 dvb_core 109716 1 dvb_usb While googling for an answer to my troubles I came across http://ubuntuforums.org/showthread.php?t=606487page=5 which hints that the card may use the TDA18218HK tuner chip which does not seem to be supported currently. Does anyone have any experience regarding this chip and know what to do to get it working. Best regards, //Jan Hi Jan, As stated in the Ubuntuforums thread, there doesn't seem to be any support for this chip at the moment. I don't know how hard it is to code support for a specific tuner, but I'm looking into that right now. Hopefully some more experienced coders will join in writing something usable, as I don't think I will be able to do it myself. Please drop a message if anyone finds something useful. Best regards, Bert The TDA18218 is not currently supported under Linux. I have the information needed to write a driver to support it, but I do not have any devices that use it, nor any interest (as of now) to write the driver on my own time. For me, it would not be very difficult to get this done, as I have done work to support a similar family of tuners -- TDA18271 / TDA18211. The TDA18218 tuner is not supported by the current driver. In the past, I would have gone ahead and written a driver for the sheer enjoyment of doing so... but nowadays, I actually have other projects of a higher priority that need my attention instead. If, in the future, any commercial entity has interest in seeing this tuner silicon supported under Linux, they should contact me -- perhaps my desire to write this driver can be increased ;-) Regards, Mike Krufky kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] Another approach to IR
On Wed, Dec 2, 2009 at 3:04 PM, Jarod Wilson ja...@wilsonet.com wrote: On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote: On 12/2/09 12:30 PM, Jon Smirl wrote: (for each remote/substream that they can recognize). I'm assuming that, by remote, you're referring to a remote receiver (and not to the remote itself), right? If we could separate by remote transmitter that would be the best I think, but I understand that it is rarely possible? The code I posted using configfs did that. Instead of making apps IR aware it mapped the vendor/device/command triplets into standard Linux keycodes. Each remote was its own evdev device. Note, of course, that you can only do that iff each remote uses distinct triplets. A good portion of mythtv users use a universal of some sort, programmed to emulate another remote, such as the mce remote bundled with mceusb transceivers, or the imon remote bundled with most imon receivers. I do just that myself. Personally, I've always considered the driver/interface to be the receiver, not the remote. The lirc drivers operate at the receiver level, anyway, and the distinction between different remotes is made by the lirc daemon. The fact that lirc does it this way does not necessarily mean it is the most corerct way. No, I know that, I'm just saying that's how I've always looked at it, and that's how lirc does it right now, not that it must be that way. Do you expect all bluetooth input devices be presented as a single blob just because they happen to talk to the sane receiver in yoru laptop? Do you expect your USB mouse and keyboard be merged together just because they end up being serviced by the same host controller? If not why remotes should be any different? A bluetooth remote has a specific device ID that the receiver has to pair with. Your usb mouse and keyboard each have specific device IDs. A usb IR *receiver* has a specific device ID, the remotes do not. So there's the major difference from your examples. Actually remotes do have an ID. They all transmit vendor/device pairs which is exactly how USB works. Now I understand that if 2 remotes send completely identical signals we won't be able to separate them, but in cases when we can I think we should. I don't have a problem with that, if its a truly desired feature. But for the most part, I don't see the point. Generally, you go from having multiple remotes, one per device (where device is your TV, amplifier, set top box, htpc, etc), to having a single universal remote that controls all of those devices. But for each device (IR receiver), *one* IR command set. The desire to use multiple distinct remotes with a single IR receiver doesn't make sense to me. Perhaps I'm just not creative enough in my use of IR. :) -- Jarod Wilson ja...@wilsonet.com -- 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: [RFC v2] Another approach to IR
On Wed, 2009-12-02 at 14:55 -0500, Jarod Wilson wrote: On Dec 2, 2009, at 2:33 PM, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: ... (for each remote/substream that they can recognize). I'm assuming that, by remote, you're referring to a remote receiver (and not to the remote itself), right? If we could separate by remote transmitter that would be the best I think, but I understand that it is rarely possible? IMHO, the better is to use a separate interface for the IR transmitters, on the devices that support this feature. There are only a few devices I'm aware of that are able to transmit IR codes. If I'm thinking clearly, there are only three lirc kernel drivers that support transmit, lirc_mceusb, lirc_zilog and lirc_serial. The mceusb driver was posted, so I won't rehash what it is here. The zilog driver binds to a Zilog z80 microprocessor thingy (iirc) exposed via i2c, found on many Hauppauge v4l/dvb devices (PVR-150, HVR-1600, HD-PVR, etc). The serial driver is fairly self-explanatory as well. There are also a few userspace-driven devices that do transmit, but I'm assuming they're (currently) irrelevant to this discussion. I've got the CX23888 integrated IR Rx done and Tx nearly done. I was waiting to see how kfifo and lirc_dev panned out before making the interface to userspace. The CX23885, CX23418, and CX2584x integrated IR is essentially the same. I hope to have CX23885 IR done by Christmas. Both of those IR devices are/will be encapsulated in a v4l2_subdevice object internally. I was going to write lirc_v4l glue between the v4l2_device/v4l2_subdev_ir_ops and lirc_dev. As for the the I2C chips, I was going to go back and encapsulate those in the v4l2_subdevice object as well, so then my notional lirc_v4l could pick those up too. The I2C subsystem only allows one binding to an I2C client address/name on a bus. So without some new glue like a notional lirc_v4l, it *may* be hard to share between ir-kbd-i2c and lirc_i2c and lirc_zilog. 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: [RFC v2] Another approach to IR
On Wed, 2009-12-02 at 12:14 -0800, Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote: Didn't Jon posted his example whith programmable remote pretending to be several separate remotes (depending on the mode of operation) so that several devices/applications can be controlled without interfering with each other? There are a few features that can be used to distinguish remotes: 1. Carrier freq 2. Protocol (NEC, Sony, JVC, RC-5...) 3. Protocol variant (NEC original, NEC with extended addresses, RC-5, RC-5 with exteneded commands, RC-6 Mode 0, RC-6 Mode 6B, ...) 4. System # or Address sent by the remote (16 bits max, I think) 5. Set of possible Commands or Information words sent from the remote. 6. Pulse width deviation from standard (mean, variance) 1, 5, and 6 are really a sort of fingerprint and likely not worth the effort, even if you have hardware that can measure things with some accuracy. 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: [RFC v2] Another approach to IR
Jon Smirl wrote: On Wed, Dec 2, 2009 at 3:04 PM, Jarod Wilson ja...@wilsonet.com wrote: On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote: On 12/2/09 12:30 PM, Jon Smirl wrote: (for each remote/substream that they can recognize). I'm assuming that, by remote, you're referring to a remote receiver (and not to the remote itself), right? If we could separate by remote transmitter that would be the best I think, but I understand that it is rarely possible? The code I posted using configfs did that. Instead of making apps IR aware it mapped the vendor/device/command triplets into standard Linux keycodes. Each remote was its own evdev device. Note, of course, that you can only do that iff each remote uses distinct triplets. A good portion of mythtv users use a universal of some sort, programmed to emulate another remote, such as the mce remote bundled with mceusb transceivers, or the imon remote bundled with most imon receivers. I do just that myself. Personally, I've always considered the driver/interface to be the receiver, not the remote. The lirc drivers operate at the receiver level, anyway, and the distinction between different remotes is made by the lirc daemon. The fact that lirc does it this way does not necessarily mean it is the most corerct way. No, I know that, I'm just saying that's how I've always looked at it, and that's how lirc does it right now, not that it must be that way. Do you expect all bluetooth input devices be presented as a single blob just because they happen to talk to the sane receiver in yoru laptop? Do you expect your USB mouse and keyboard be merged together just because they end up being serviced by the same host controller? If not why remotes should be any different? A bluetooth remote has a specific device ID that the receiver has to pair with. Your usb mouse and keyboard each have specific device IDs. A usb IR *receiver* has a specific device ID, the remotes do not. So there's the major difference from your examples. Actually remotes do have an ID. They all transmit vendor/device pairs which is exactly how USB works. Well, the description of NEC and RC5 protocol at http://www.sbprojects.com/knowledge/ir/rc5.htm doesn't mention any vendor/device pair, nor I'm able to get them with the IR hardware decoders I have. Do you have any info on how they're encoded? 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 v2] Another approach to IR
Am Mittwoch, den 02.12.2009, 20:19 -0500 schrieb Andy Walls: On Wed, 2009-12-02 at 12:14 -0800, Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote: Didn't Jon posted his example whith programmable remote pretending to be several separate remotes (depending on the mode of operation) so that several devices/applications can be controlled without interfering with each other? There are a few features that can be used to distinguish remotes: 1. Carrier freq 2. Protocol (NEC, Sony, JVC, RC-5...) 3. Protocol variant (NEC original, NEC with extended addresses, RC-5, RC-5 with exteneded commands, RC-6 Mode 0, RC-6 Mode 6B, ...) 4. System # or Address sent by the remote (16 bits max, I think) 5. Set of possible Commands or Information words sent from the remote. 6. Pulse width deviation from standard (mean, variance) 1, 5, and 6 are really a sort of fingerprint and likely not worth the effort, even if you have hardware that can measure things with some accuracy. I don't follow closely enough, but eventually we have (different) remotes a receiver chip can distinguish in hardware, firmware might be involved too. If I don't get it wrong, Dmitry is asking in the first place, how such sender receiver combinations switch to different emulated digital information for a bunch of different types of hardware in living rooms. Starting with RC5, IIRC, there is of course such switch over to another device around. We are only one more. To repeat, on such bundled cheapest remotes with some TV/DVB cards around, there are only some minimal implementations of RC5, likely they use that protocol even illegally, at least they make chips in use unidentifiable and this seems to be by will. So, if some try to implement now the highest level, they are far away from to know what hardware goes how far with them. At least fun to see they have some starting point ;) Cheers, 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: [RFC v2] Another approach to IR
On Wed, 2 Dec 2009, Jon Smirl wrote: A bluetooth remote has a specific device ID that the receiver has to pair with. Your usb mouse and keyboard each have specific device IDs. A usb IR *receiver* has a specific device ID, the remotes do not. So there's the major difference from your examples. Actually remotes do have an ID. They all transmit vendor/device pairs which is exactly how USB works. *All* remotes? That's a bold statement. I'm sure there are some that only transmit 8 bits of so of scancode. I think remotes are more like hosts on a network than usb or bluetooth devices. Remotes do not join or leave a receiver, while things like usb devices do explictly join and leave the hub. Now I understand that if 2 remotes send completely identical signals we won't be able to separate them, but in cases when we can I think we should. I don't have a problem with that, if its a truly desired feature. But for the most part, I don't see the point. Generally, you go from having multiple remotes, one per device (where device is your TV, amplifier, set top box, htpc, etc), to having a single universal remote that controls all of those devices. But for each device (IR receiver), *one* IR command set. The desire to use multiple distinct remotes with a single IR receiver doesn't make sense to me. Perhaps I'm just not creative enough in my use of IR. :) Most universal remotes I'm familiar with emulate multiple remotes. I.e. my tv remote generates one set of scancodes for the numeric keys. The DVD remote generates a different set. The amplifier remote in tv mode generates the same codes as the tv remote, and in dvd mode the same codes as the dvd remote. From the perspective of the IR receiver there is no difference between having both the DVD and TV remotes, or using the aplifier remote to control both devices. Now, my aplifier remote has a number of modes. Some control devices I have, like vcr mode, and there is nothing I can do about that. Some, like md mode don't control devices I have. That means they are free to do things on the computer. Someone else with the same remote (or any number of remotes that use the same protocol and scancodes) might have different devices. So I want my computer to do stuff when I push JVC MD #xx keys, but ignore JVC VCR #yyy yets. Someone with an MD player and not a VCR would want to opposite. Rather than force everyone to create custom keymaps, it's much easier if we can use the standard keymaps from a database of common remotes and simply tell mythtv to only use remote #xxx or not to use remote #yyy. It sounds like you're thinking of a receiver that came bundled with a remote and that's it. Not someone with a number of remotes that came with different pieces of AV gear that they want to use with their computer. -- 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 v2] Another approach to IR
On Dec 2, 2009, at 9:48 PM, Trent Piepho wrote: ... Now I understand that if 2 remotes send completely identical signals we won't be able to separate them, but in cases when we can I think we should. I don't have a problem with that, if its a truly desired feature. But for the most part, I don't see the point. Generally, you go from having multiple remotes, one per device (where device is your TV, amplifier, set top box, htpc, etc), to having a single universal remote that controls all of those devices. But for each device (IR receiver), *one* IR command set. The desire to use multiple distinct remotes with a single IR receiver doesn't make sense to me. Perhaps I'm just not creative enough in my use of IR. :) Most universal remotes I'm familiar with emulate multiple remotes. I.e. my tv remote generates one set of scancodes for the numeric keys. The DVD remote generates a different set. The amplifier remote in tv mode generates the same codes as the tv remote, and in dvd mode the same codes as the dvd remote. From the perspective of the IR receiver there is no difference between having both the DVD and TV remotes, or using the aplifier remote to control both devices. Okay, in the above scenario, you've still got a single input device... Now, my aplifier remote has a number of modes. Some control devices I have, like vcr mode, and there is nothing I can do about that. Some, like md mode don't control devices I have. That means they are free to do things on the computer. Someone else with the same remote (or any number of remotes that use the same protocol and scancodes) might have different devices. So I want my computer to do stuff when I push JVC MD #xx keys, but ignore JVC VCR #yyy yets. Someone with an MD player and not a VCR would want to opposite. Rather than force everyone to create custom keymaps, it's much easier if we can use the standard keymaps from a database of common remotes and simply tell mythtv to only use remote #xxx or not to use remote #yyy. Sure, but the key is that this can't be done automagically. The IR driver has no way of knowing that user A wants JVC MD keys handled and JVC VCR keys ignored, and user B wants vice versa, while user C wants both ignored, etc. This is somewhat tangential to whether or not there's a separate input device per remote though. You can use multiple remotes/protocols with a single input device or lirc device already (if the hardware doesn't have to be put explicitly into a mode to listen for that proto, of course, but then its a hardware decoding device feeding a single input device anyway, so...). It sounds like you're thinking of a receiver that came bundled with a remote and that's it. Not someone with a number of remotes that came with different pieces of AV gear that they want to use with their computer. No, I just pick *one* remote and use it for everything, not schizophrenically hopping from one remote to another, expecting them all the be able to control everything. :) Its a hell of a lot easier to find buttons w/o looking at the remote if you always use the same one for everything, for one. Anyway, I think I'm talking myself in circles. Supporting multiple remotes via multiple input devices (or even via a single input device) isn't at all interesting to me for my own use, but if there really is demand for such support (and it appears there is), then fine, lets do it. -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Dec 1, 2009, at 10:28 AM, Gerd Hoffmann wrote:
Anyway, we shouldn't postpone lirc drivers addition due to that. There are
still lots of work
to do before we'll be able to split the tables from the kernel drivers.
Indeed. The sysfs bits are future work for both lirc and evdev drivers.
There is no reason to make the lirc merge wait for it.
At this point, my plan is to try to finish cleaning up lirc_dev and lirc_mceusb
at least over the weekend while at FUDCon up in Toronto, and resubmit them next
week.
I'm still on the fence over what to do about lirc_imon. The driver supports
essentially 3 generations of devices. First-gen is very old imon parts that
don't do onboard decoding. Second-gen is the devices that all got (insanely
stupidly) tagged with the exact same usb device ID (0x15c2:0xffdc), some of
which have an attached VFD, some with an attached LCD, some with neither, some
that are actually RF parts, but all (I think) of which do onboard decoding.
Third-gen is the latest stuff, which is all pretty sane, unique device IDs for
unique devices, onboard decoding, etc.
So the lirc_imon I submitted supports all device types, with the onboard decode
devices defaulting to operating as pure input devices, but an option to pass
hex values out via the lirc interface (which is how they've historically been
used -- the pure input stuff I hacked together just a few weeks ago), to
prevent functional setups from being broken for those who prefer the lirc way.
What I'm debating is whether this should be split into two drivers, one for the
older devices that don't do onboard decoding (which would use the lirc_dev
interface) called 'lirc_imon' or 'lirc_imon_legacy', and one that is a pure
input driver, not unlike the ati_remote{,2} drivers, with no lirc_dev
dependency at all, probably called simply 'imon'. Could still be used with lirc
via its devinput userspace driver, of course. But if I split it out, there may
end up being a fair amount of code duplication, and the resulting lirc_imon
wouldn't be as interesting to submit, and I wouldn't have any devices that
worked with it, I've only got onboard decode devices... The new imon input
driver would be a separate submission that is completely irrelevant to this
whole discussion.
So perhaps for round three, lirc_dev, lirc_mceusb and lirc_zilog, to make it
more interesting...
--
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
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings for the following: - v4l: Adding Digital Video Timings APIs - v4l2-spec: Digital Video Timings API documentation - v4l2-spec: updated revision history, updated version to 2.6.33. Murali, I've added you as one of the authors of the v4l2-spec (you did this timings API after all) and included your email as well. If that is a problem for you (either being mentioned at all, or that your email is mentioned), then let me know asap and I'll remove it. I don't expect it to be a problem since all this information is already public. Mauro, before adding these documentation patches it is probably a good idea to build and release a final 2.6.32 version of the documentation on http://www.linuxtv.org/docs.php. If you want to see an example of this api being used, then take a look at the tvp7002 driver patches that have been posted recently. I expect that driver to be merged soon after this pull request is merged. Thanks, Hans diffstat: b/linux/Documentation/DocBook/v4l/vidioc-enum-dv-presets.xml | 238 +++ b/linux/Documentation/DocBook/v4l/vidioc-g-dv-preset.xml | 111 + b/linux/Documentation/DocBook/v4l/vidioc-g-dv-timings.xml| 224 ++ b/linux/Documentation/DocBook/v4l/vidioc-query-dv-preset.xml | 85 +++ linux/Documentation/DocBook/media-entities.tmpl | 18 linux/Documentation/DocBook/media-indices.tmpl |4 linux/Documentation/DocBook/v4l/common.xml | 35 + linux/Documentation/DocBook/v4l/compat.xml | 16 linux/Documentation/DocBook/v4l/v4l2.xml | 26 + linux/Documentation/DocBook/v4l/videodev2.h.xml | 116 + linux/Documentation/DocBook/v4l/vidioc-enuminput.xml | 36 + linux/Documentation/DocBook/v4l/vidioc-enumoutput.xml| 36 + linux/drivers/media/video/v4l2-compat-ioctl32.c |6 linux/drivers/media/video/v4l2-ioctl.c | 147 ++ linux/include/linux/videodev2.h | 116 + linux/include/media/v4l2-ioctl.h | 15 linux/include/media/v4l2-subdev.h| 21 media-specs/Makefile | 14 18 files changed, 1252 insertions(+), 12 deletions(-) -- 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: Replace Mercurial with GIT as SCM
On Wednesday 02 December 2009 04:55:00 Andy Walls wrote: On Tue, 2009-12-01 at 15:59 +0100, Patrick Boettcher wrote: Hi all, I would like to start a discussion which ideally results in either changing the SCM of v4l-dvb to git _or_ leaving everything as it is today with mercurial. I'm waiting for comments. I only have one requirement: reduce bandwidth usage between the server and my home. The less I have to clone out 65 M of history to start a new series of patches the better. I suppose that would include a rebase... Unfortunately, one reason for moving to git would be to finally be able to make changes to the arch directory tree. The fact that that part is unavailable in v4l-dvb is a big problem when working with SoCs. And these will become much more important in the near future. Regards, Hans 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 -- 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 v2] Another approach to IR
On Wed, Dec 2, 2009 at 9:22 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Wed, Dec 2, 2009 at 3:04 PM, Jarod Wilson ja...@wilsonet.com wrote: On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote: On 12/2/09 12:30 PM, Jon Smirl wrote: (for each remote/substream that they can recognize). I'm assuming that, by remote, you're referring to a remote receiver (and not to the remote itself), right? If we could separate by remote transmitter that would be the best I think, but I understand that it is rarely possible? The code I posted using configfs did that. Instead of making apps IR aware it mapped the vendor/device/command triplets into standard Linux keycodes. Each remote was its own evdev device. Note, of course, that you can only do that iff each remote uses distinct triplets. A good portion of mythtv users use a universal of some sort, programmed to emulate another remote, such as the mce remote bundled with mceusb transceivers, or the imon remote bundled with most imon receivers. I do just that myself. Personally, I've always considered the driver/interface to be the receiver, not the remote. The lirc drivers operate at the receiver level, anyway, and the distinction between different remotes is made by the lirc daemon. The fact that lirc does it this way does not necessarily mean it is the most corerct way. No, I know that, I'm just saying that's how I've always looked at it, and that's how lirc does it right now, not that it must be that way. Do you expect all bluetooth input devices be presented as a single blob just because they happen to talk to the sane receiver in yoru laptop? Do you expect your USB mouse and keyboard be merged together just because they end up being serviced by the same host controller? If not why remotes should be any different? A bluetooth remote has a specific device ID that the receiver has to pair with. Your usb mouse and keyboard each have specific device IDs. A usb IR *receiver* has a specific device ID, the remotes do not. So there's the major difference from your examples. Actually remotes do have an ID. They all transmit vendor/device pairs which is exactly how USB works. Well, the description of NEC and RC5 protocol at http://www.sbprojects.com/knowledge/ir/rc5.htm doesn't mention any vendor/device pair, nor I'm able to get them with the IR hardware decoders I have. Some of the protocols were not intended to be multi-vendor - the vendor is implicit in the protocol encoding. You don't have to split the IR codes into vendor/device/command triplets. I just do that because it is convenient to think of them that way. It is equally valid to treat them as a 64b integers and use four bits of the int to encode the protocol. It should really be a quad protocol/vendor/device/command and some of the fields may be missing. Bottom line, you are looking for unique codes how the fields are split up doesn't really matter. A fixed protocol receiver is more of a challenge. You have to figure out how to make a universal remote transmit device codes for a device you don't already own that is also encoded in the protocol your hardware supports. There's nothing we can do about that problem in Linux, its a side effect of fixed protocol decode hardware. You're just going to have to start guessing devices in the remote until you find one that uses your fixed protocol and doesn't also activate the devices you own. We can put suggestions in the doc when working devices are discovered. With a universal receiver the problem is simpler, just pick a device you don't own - the encoding protocol doesn't matter. These are generic problems with IR that are the same no matter how things get implemented in Linux. -- 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: [RFC v2] Another approach to IR
On Wed, Dec 2, 2009 at 11:13 PM, Jarod Wilson ja...@wilsonet.com wrote: On Dec 2, 2009, at 9:48 PM, Trent Piepho wrote: ... Now I understand that if 2 remotes send completely identical signals we won't be able to separate them, but in cases when we can I think we should. I don't have a problem with that, if its a truly desired feature. But for the most part, I don't see the point. Generally, you go from having multiple remotes, one per device (where device is your TV, amplifier, set top box, htpc, etc), to having a single universal remote that controls all of those devices. But for each device (IR receiver), *one* IR command set. The desire to use multiple distinct remotes with a single IR receiver doesn't make sense to me. Perhaps I'm just not creative enough in my use of IR. :) Most universal remotes I'm familiar with emulate multiple remotes. I.e. my tv remote generates one set of scancodes for the numeric keys. The DVD remote generates a different set. The amplifier remote in tv mode generates the same codes as the tv remote, and in dvd mode the same codes as the dvd remote. From the perspective of the IR receiver there is no difference between having both the DVD and TV remotes, or using the aplifier remote to control both devices. Okay, in the above scenario, you've still got a single input device... Now, my aplifier remote has a number of modes. Some control devices I have, like vcr mode, and there is nothing I can do about that. Some, like md mode don't control devices I have. That means they are free to do things on the computer. Someone else with the same remote (or any number of remotes that use the same protocol and scancodes) might have different devices. So I want my computer to do stuff when I push JVC MD #xx keys, but ignore JVC VCR #yyy yets. Someone with an MD player and not a VCR would want to opposite. Rather than force everyone to create custom keymaps, it's much easier if we can use the standard keymaps from a database of common remotes and simply tell mythtv to only use remote #xxx or not to use remote #yyy. Sure, but the key is that this can't be done automagically. The IR driver has no way of knowing that user A wants JVC MD keys handled and JVC VCR keys ignored, and user B wants vice versa, while user C wants both ignored, etc. This is somewhat tangential to whether or not there's a separate input device per remote though. You can use multiple remotes/protocols with a single input device or lirc device already (if the hardware doesn't have to be put explicitly into a mode to listen for that proto, of course, but then its a hardware decoding device feeding a single input device anyway, so...). It sounds like you're thinking of a receiver that came bundled with a remote and that's it. Not someone with a number of remotes that came with different pieces of AV gear that they want to use with their computer. No, I just pick *one* remote and use it for everything, not schizophrenically hopping from one remote to another, expecting them all the be able to control everything. :) Its a hell of a lot easier to find buttons w/o looking at the remote if you always use the same one for everything, for one. Anyway, I think I'm talking myself in circles. Supporting multiple remotes via multiple input devices (or even via a single input device) isn't at all interesting to me for my own use, but if there really is demand for such support (and it appears there is), then fine, lets do it. Simple use case: You have a multifunction remote. Press the CABLE key - it sends out commands that control the cable box, press the TV key - now the commands control the TV, press CD - now the CD player, etc. Now imagine a headless Linux box running a music server and a home automation app. Press the CD key - commands get routed to the music server, press the AUX key - commands get routed to the home automation app. This is accomplished by recognizing the device code part of the IR signal and figuring out that there are two different device codes in use. The commands of then routed to two evdev devices corresponding to the two different device codes. Using things like Alt-Tab to switch apps is impossible. There's no screen to look at. -- Jarod Wilson ja...@wilsonet.com -- 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: [Bugme-new] [Bug 14564] New: capture-example sleeping function called from invalid context at arch/x86/mm/fault.c
Is there anything I can do to help? This is a show stopping bug for me. Thanks, Sean Lazar Alan Stern wrote: On Wed, 11 Nov 2009, Andrew Morton wrote: http://bugzilla.kernel.org/show_bug.cgi?id=14564 Summary: capture-example sleeping function called from invalid context at arch/x86/mm/fault.c We oopsed in td_free() (see below). But as part of that oops processing the kernel entered do_page_fault() and emitted a might_sleep() warning because we took a pagefault with local interrupts disabled. This is undesirable behaviour from the low-level x86 fault code and I don't think it normally happens. Did we break something in x86 land, or is this oops sufficiently weird and whacky to bypass existing checks for this false positive? No, what happened was a structure containing a linked-list entry got freed while it was still on the list. Then when the driver walked through the list, it attempted to dereference a list pointer that had been poisoned. More or less by coincidence, the poison value represented a paged-out address rather than an invalid address, so a page fault occurred. That's what caused the oops. BUG: unable to handle kernel paging request at a7a7a7c3 IP: [c11c5cef] td_free+0x23/0x75 [c1155a42] ? tty_ldisc_deref+0x8/0xa [c1150c1c] ? tty_write+0x1b1/0x1c2 [c1152d69] ? n_tty_write+0x0/0x2e6 [c1150a6b] ? tty_write+0x0/0x1c2 [c106431d] ? vfs_write+0xe3/0xfa [c1002858] ? restore_all_notrace+0x0/0x18 [c106e3e2] ? sys_ioctl+0x2c/0x45 [c1002825] ? syscall_call+0x7/0xb Code: e5 e8 bf 7b e9 ff 5d c3 55 89 e5 57 89 c7 56 89 d6 53 8b 42 28 89 c2 c1 ea 06 31 d0 83 e0 3f 8d 94 87 cc 00 00 00 eb 03 8d 50 1c 8b 02 85 c0 74 0b 39 EIP: [c11c5cef] td_free+0x23/0x75 SS:ESP 0068:c6785cb8 CR2: a7a7a7c3 And here's the real oops. drivers/usb/host/ohci-mem.c:td_free() dereferenced a7a7a7c3. Which looks like /** drivers/base/dmapool.c **/ #define POOL_POISON_FREED 0xa7/* !inuse */ #define POOL_POISON_ALLOCATED 0xa9/* !initted */ If I'm reading this correctly, the bad dereference occurred in the second source line: prev = (*prev)-td_hash; if (*prev) The original value in *prev was 0xa7a7a7a7 and the offset of td_hash is 0x1c, causing the offending address to be 0xa7a7a7c3. I have no idea why a struct td would have been freed while it was still in use. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH - v0 2/2] DaVinci - vpfe capture - Make clocks configurable
-Original Message-
From: Karicheri, Muralidharan
Sent: Tuesday, December 01, 2009 10:49 PM
To: linux-media@vger.kernel.org; hverk...@xs4all.nl;
khil...@deeprootsystems.com
Cc: davinci-linux-open-sou...@linux.davincidsp.com; Hiremath,
Vaibhav; Karicheri, Muralidharan
Subject: [PATCH - v0 2/2] DaVinci - vpfe capture - Make clocks
configurable
From: Muralidharan Karicheri m-kariche...@ti.com
Adding the clocks in vpfe capture configuration
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
arch/arm/mach-davinci/board-dm355-evm.c |2 ++
arch/arm/mach-davinci/board-dm644x-evm.c |2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c
b/arch/arm/mach-davinci/board-dm355-evm.c
index a9b650d..a28985c 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -239,6 +239,8 @@ static struct vpfe_config vpfe_cfg = {
.sub_devs = vpfe_sub_devs,
.card_name = DM355 EVM,
.ccdc = DM355 CCDC,
+ .num_clocks = 2,
+ .clocks = {vpss_master, vpss_slave},
[Hiremath, Vaibhav] Hi Murali,
I was talking to Sekhar about this and actually he made some good points about
this implementation.
If we consider specific IP, then the required clocks would remain always be the
same. There might be some devices which may not be using some clocks (so as
that specific feature).
Actually we are trying to create one more wrapper for clock configuration. Just
to illustrate I am putting some other generic drivers examples -
Omap-hsmmc.c -
This driver requires 2 clocks, interface and functional. The devices which
would be using this driver have to define clock with names ick and fck.
VPFE-Capture (Considering only current implementation) -
Currently we have vpfe_capture.c file (master/bridge driver) which is handling
clk_get/put, and platform data is providing the details about it.
Ideally we should handle it in respective ccdc driver file, since he has all
the knowledge about required number of clocks and its name. This way we don't
have to maintain/pass clock information in platform data.
I would appreciate any comments/thoughts/pointers here.
Thanks,
Vaibhav
};
static struct platform_device *davinci_evm_devices[] __initdata = {
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index fd0398b..45beb99 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -250,6 +250,8 @@ static struct vpfe_config vpfe_cfg = {
.sub_devs = vpfe_sub_devs,
.card_name = DM6446 EVM,
.ccdc = DM6446 CCDC,
+ .num_clocks = 2,
+ .clocks = {vpss_master, vpss_slave},
};
static struct platform_device rtc_dev = {
--
1.6.0.4
--
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: Replace Mercurial with GIT as SCM
+1 for git, I really really really miss being able to do a simple git rebase, and no rebase is not evil not as long as you don't use it for anything but local patches. Regards, Hans On 12/01/2009 03:59 PM, Patrick Boettcher wrote: Hi all, I would like to start a discussion which ideally results in either changing the SCM of v4l-dvb to git _or_ leaving everything as it is today with mercurial. To start right away: I'm in favour of using GIT because of difficulties I have with my daily work with v4l-dvb. It is in my nature do to mistakes, so I need a tool which assists me in fixing those, I have not found a simple way to do my stuff with HG. I'm helping out myself using a citation from which basically describes why GIT fits the/my needs better than HG (*): The culture of mercurial is one of immutability. This is quite a good thing, and it's one of my favorite aspects of gnu arch. If I commit something, I like to know that it's going to be there. Because of this, there are no tools to manipulate history by default. git is all about manipulating history. There's rebase, commit amend, reset, filter-branch, and probably other commands I'm not thinking of, many of which make it into day-to-day workflows. Then again, there's reflog, which adds a big safety net around this mutability. The first paragraph here describes exactly my problem and the second descibes how to solve it. My suggestion is not to have the full Linux Kernel source as a new base for v4l-dvb development, but only to replace the current v4l-dvb hg with a GIT one. Importing all the history and everything. Unfortunately it will change nothing for Mauro's job. I also understand that it does not give a lot to people who haven't used GIT until now other than a new SCM to learn. But believe me, once you've done a rebase when Mauro has asked you to rebuild your tree before he can merge it, you will see what I mean. I'm waiting for comments. Thanks, (*) http://www.rockstarprogrammer.org/post/2008/apr/06/differences-between-mercurial-and-git/ -- Patrick http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
