Re: [PATCH 1/2 v3] v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats

2009-12-02 Thread Guennadi Liakhovetski
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

2009-12-02 Thread Paul

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

2009-12-02 Thread Dmitry Torokhov
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

2009-12-02 Thread Gerd Hoffmann

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

2009-12-02 Thread Mauro Carvalho Chehab
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

2009-12-02 Thread Mauro Carvalho Chehab
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

2009-12-02 Thread Ondrej Zary
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

2009-12-02 Thread HoP
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


TT S2-3200

2009-12-02 Thread Andreas Zwicker

Hi,

I have problems with my new TT S2-3200 DVB-S2 cards. Tuning / scanning 
with scan-s2 / szap-s2 is fine ( well almost ). My two satellite dishes 
are directing towards Astra 19.2E / Astra 28.2E.
I'm using Debian Lenny with a custom build 2.6.31 kernel und dvb-s2 
drivers from the v4l-dvb repository.


The dvb channel scanner in mythtv 0.22 has massive locking problems. 
Most of the found channels are not tunable. Arte works almost, RTL is 
found but is not tunable.


Mythtv contains a so called signalmonitor. This signalmonitor checks 40 
times a second the status of the dvb frontend. I've patched the 
signalmonitor calls from 40 times to 2 times a second. With this patch, 
the channelscanner works und nearly all channels are tunable.


Where is the problem? My old Skystar 2 TV PCI DVB-S cards are running 
with no problem with the same system / software / dishes / coax cable 
and 40 Status calls a second.


thanks in advance for your advice,

Andreas
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


TBS 6980 Dual DVB-S2 PCIe card

2009-12-02 Thread Thomas Kernen


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

2009-12-02 Thread Devin Heitmueller
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

2009-12-02 Thread Felix Radensky

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: [RFC v2] Another approach to IR

2009-12-02 Thread Jon Smirl
On Wed, Dec 2, 2009 at 4:38 AM, Dmitry Torokhov
dmitry.torok...@gmail.com 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 FIFO will have to appear as a /dev/device or be in debugfs. GregKH
sent earlier mail telling me to get the FIFO out of sysfs.

 - 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 includes defining IR events for evdev with vendor/device/command triplets?
You need those standard events to make apps IR aware.

LIRC will also need to inject those events after decoding pulse data.


 This way there is clear layering, protocol selection is kept at lirc
 level.

Did you checkout 

RE: [PATCH] V4L - Fix videobuf_dma_contig_user_get() getting page aligned physical address

2009-12-02 Thread Karicheri, Muralidharan
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


knc1 dvb-c plus doesn't work with kenrel 2.6.31

2009-12-02 Thread Halim Sahin
Hello list,
The mentioned card doesnÄ't work any more.
I am running an opensuse 2.6.31 kernel.
It sems that no frontend can be loaded.
I am getting also many cam inserted or cam ejected messages.

dmesg contains this message:

[ 1067.280898] budget-av: A frontend driver was not found for device
[1131:7146]
 subsystem [1894:0021]

lspci -vvv
01:05.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
Subsystem: KNC One Device 0021
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
Stepping- S
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort-
TAbort- MAbo
Latency: 64 (3750ns min, 9500ns max)
Interrupt: pin A routed to IRQ 18
Region 0: [virtual] Memory at 8000 (32-bit, non-prefetchable)
[size=512]
Kernel driver in use: budget_av
ny ideas?

Regards
Halim

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH 1/5 - v0] V4L-vpfe capture - adding CCDC driver for DM365

2009-12-02 Thread Nori, Sekhar
Hi Murali,

Here is a (styling related) review from an non-video person. The
review is neither complete nor exhaustive (the patch is huge!),
but I thought will send across whatever I have for you to take a look.

On Wed, Dec 02, 2009 at 03:08:49, Karicheri, Muralidharan wrote:
 From: Muralidharan Karicheri m-kariche...@ti.com

 This patch is for adding support for DM365 CCDC. This will allow to
 capture YUV video frames from TVP5146 video decoder on DM365 EVM. The vpfe
 capture driver will use this module to configure ISIF (a.k.a CCDC)
 module to allow YUV data capture. This driver is written for ccdc_hw_device
 interface used by vpfe capture driver to configure the ccdc module.
 This patch is tested using NTSC  PAL video sources and verified for
 both formats.

 NOTE: This is the initial version for review.

Typically RFC is put instead of PATCH in subject line
to convey this.


 Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
 ---
  drivers/media/video/davinci/dm365_ccdc.c  | 1529 
 +
  drivers/media/video/davinci/dm365_ccdc_regs.h |  293 +
  include/media/davinci/dm365_ccdc.h|  555 +
  3 files changed, 2377 insertions(+), 0 deletions(-)
  create mode 100644 drivers/media/video/davinci/dm365_ccdc.c
  create mode 100644 drivers/media/video/davinci/dm365_ccdc_regs.h
  create mode 100644 include/media/davinci/dm365_ccdc.h

 diff --git a/drivers/media/video/davinci/dm365_ccdc.c 
 b/drivers/media/video/davinci/dm365_ccdc.c

Hopefully it is possible to choose a generic name
instead of tying it to an SoC.

 new file mode 100644
 index 000..2f27696
 --- /dev/null
 +++ b/drivers/media/video/davinci/dm365_ccdc.c
 @@ -0,0 +1,1529 @@

[...]

 +#include linux/delay.h
 +#include linux/platform_device.h
 +#include linux/uaccess.h
 +#include linux/io.h
 +#include linux/videodev2.h
 +#include mach/mux.h
 +#include media/davinci/dm365_ccdc.h
 +#include media/davinci/vpss.h
 +#include dm365_ccdc_regs.h
 +#include ccdc_hw_device.h

Typically the includes are grouped using empty lines
based on the folder linux, media mach etc.

 +
 +static struct device *dev;
 +
 +/* Defauts for module configuation paramaters */
 +static struct ccdc_config_params_raw ccdc_config_defaults = {
 + .linearize = {
 + .en = 0,
 + .corr_shft = CCDC_NO_SHIFT,
 + .scale_fact = {1, 0},
 + },
 + .df_csc = {
 + .df_or_csc = 0,
 + .csc = {
 + .en = 0

Should use ',' at the end of line so adding
new members leads to adding just one line.
There are more of these in this static init
below.

 + },
 + },
 + .dfc = {
 + .en = 0
 + },
 + .bclamp = {
 + .en = 0
 + },
 + .gain_offset = {
 + .gain = {
 + .r_ye = {1, 0},
 + .gr_cy = {1, 0},
 + .gb_g = {1, 0},
 + .b_mg = {1, 0},
 + },
 + },
 + .culling = {
 + .hcpat_odd = 0xff,
 + .hcpat_even = 0xff,
 + .vcpat = 0xff
 + },
 + .compress = {
 + .alg = CCDC_ALAW,
 + },
 +};
 +
 +/* ISIF operation configuration */
 +struct ccdc_oper_config {
 + enum vpfe_hw_if_type if_type;
 + struct ccdc_ycbcr_config ycbcr;
 + struct ccdc_params_raw bayer;
 + enum ccdc_data_pack data_pack;
 + void *__iomem base_addr;
 + void *__iomem linear_tbl0_addr;
 + void *__iomem linear_tbl1_addr;

Usually it is void __iomem *foo;

 +};
 +
 +static struct ccdc_oper_config ccdc_cfg = {
 + .ycbcr = {
 + .pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
 + .frm_fmt = CCDC_FRMFMT_INTERLACED,
 + .win = CCDC_WIN_NTSC,
 + .fid_pol = VPFE_PINPOL_POSITIVE,
 + .vd_pol = VPFE_PINPOL_POSITIVE,
 + .hd_pol = VPFE_PINPOL_POSITIVE,
 + .pix_order = CCDC_PIXORDER_CBYCRY,
 + .buf_type = CCDC_BUFTYPE_FLD_INTERLEAVED,
 + },
 + .bayer = {
 + .pix_fmt = CCDC_PIXFMT_RAW,
 + .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
 + .win = CCDC_WIN_VGA,
 + .fid_pol = VPFE_PINPOL_POSITIVE,
 + .vd_pol = VPFE_PINPOL_POSITIVE,
 + .hd_pol = VPFE_PINPOL_POSITIVE,
 + .gain = {
 + .r_ye = {1, 0},
 + .gr_cy = {1, 0},
 + .gb_g = {1, 0},
 + .b_mg = {1, 0},
 + },
 + .cfa_pat = CCDC_CFA_PAT_MOSAIC,
 + .data_msb = CCDC_BIT_MSB_11,
 + .config_params = {
 + .data_shift = CCDC_NO_SHIFT,
 + .col_pat_field0 = {
 + .olop = CCDC_GREEN_BLUE,
 + .olep = CCDC_BLUE,
 + .elop = CCDC_RED,
 + .elep = CCDC_GREEN_RED,
 + },
 + 

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Dmitry Torokhov
On Wed, Dec 02, 2009 at 10:37:02AM -0500, Jon Smirl wrote:
 On Wed, Dec 2, 2009 at 4:38 AM, Dmitry Torokhov
 dmitry.torok...@gmail.com 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 FIFO will have to appear as a /dev/device or be in debugfs. GregKH
 sent earlier mail telling me to get the FIFO out of sysfs.


No, I expect it not to be directly exposed to userspace at all, just a
part of in-kernel subsystem API. This is the way interfaces/decoders
will communicate with drivers. lirc_dev interface will take data from
fifo and send to userspace.

  - 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.
  

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Dmitry Torokhov
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 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, 

Re: [PATCH 1/2 v3] v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats

2009-12-02 Thread Hans Verkuil
On Wednesday 02 December 2009 13:32:35 Guennadi Liakhovetski wrote:
 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.

I agree that this is dragging on a bit too long. The main reason is my busy 
schedule since normally we could hash this out quickly on irc. Apologies for 
that.

 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?

Yup.


   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 

[PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/

2009-12-02 Thread Jean-Francois Moine
Hi Mauro,

Please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb

for the following 9 changesets:

01/09: gspca - pac7302: Some webcams are upside-down by default.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=8ed945771a5a

02/09: gspca - main: Cleanup source.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=3a5f10eedcde

03/09: gspca - main: Remove unnecessary set to alternate 0.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=ff8fa5a925db

04/09: gspca - doc: Update webcam list.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=9407fb6b5b6e

05/09: gspca - zc3xx: Bad sensor probe of the webcam 0ac8:305b.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=c7ed6e1e0ec3

06/09: gspca - main: Implement vidioc_enum_frameintervals.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=c18f64aaf30d

07/09: gspca - pac7302: One more webcam is upside-down by default.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=dc7a3064f0f4

08/09: gspca - main: New variable usb_err for USB exchanges.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=0d33ae310ca3

09/09: gspca - sunplus/stk014: Propagate errors to higher level.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=3dfc2ce2c655


 Documentation/video4linux/gspca.txt |   34 +++--
 drivers/media/video/gspca/gspca.c   |   52 ++-
 drivers/media/video/gspca/gspca.h   |   10 +
 drivers/media/video/gspca/pac7302.c |   21 ++-
 drivers/media/video/gspca/stk014.c  |  106 
 drivers/media/video/gspca/sunplus.c |  237 +---
 drivers/media/video/gspca/zc3xx.c   |   37 +++--
 7 files changed, 287 insertions(+), 210 deletions(-)

Thanks.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: linux-next: Tree for November 30 (media/common/tuners/max2165)

2009-12-02 Thread Randy Dunlap
On Mon, 30 Nov 2009 10:07:21 -0800 Randy Dunlap wrote:

 Stephen Rothwell wrote:
  Hi all,
  
  Changes since 20091127:
  
  The v4l-dvb tree lost its conflict.
 
 
 on i386 (X86_32):
 
 a 'double' variable is used, causing:
 
 ERROR: __floatunsidf [drivers/media/common/tuners/max2165.ko] undefined!
 ERROR: __adddf3 [drivers/media/common/tuners/max2165.ko] undefined!
 ERROR: __fixunsdfsi [drivers/media/common/tuners/max2165.ko] undefined!


linux-next-20091202:

still have this one (above) and similar with
drivers/media/dvb/frontends/atbm8830.c:

drivers/built-in.o: In function `atbm8830_init':
atbm8830.c:(.text+0x9012f9): undefined reference to `__udivdi3'
atbm8830.c:(.text+0x901384): undefined reference to `__floatunsidf'
atbm8830.c:(.text+0x901395): undefined reference to `__muldf3'
atbm8830.c:(.text+0x9013a5): undefined reference to `__floatunsidf'
atbm8830.c:(.text+0x9013b2): undefined reference to `__divdf3'
atbm8830.c:(.text+0x9013c3): undefined reference to `__muldf3'
atbm8830.c:(.text+0x9013cd): undefined reference to `__fixunsdfsi'

---
~Randy
--
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

2009-12-02 Thread Dmitry Torokhov
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

2009-12-02 Thread Jon Smirl
On Wed, Dec 2, 2009 at 1:23 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
 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 

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Jarod Wilson

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

2009-12-02 Thread Mauro Carvalho Chehab
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

2009-12-02 Thread Hans Verkuil
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

2009-12-02 Thread Jon Smirl
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

2009-12-02 Thread Jarod Wilson
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

2009-12-02 Thread Dmitry Torokhov
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

2009-12-02 Thread Jon Smirl
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

2009-12-02 Thread Dmitry Torokhov
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

2009-12-02 Thread Jarod Wilson
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

2009-12-02 Thread Dmitry Torokhov
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

2009-12-02 Thread Mauro Carvalho Chehab
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

2009-12-02 Thread Jarod Wilson
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

2009-12-02 Thread Dmitry Torokhov
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

2009-12-02 Thread Mauro Carvalho Chehab
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

2009-12-02 Thread Dmitry Torokhov
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

2009-12-02 Thread Mauro Carvalho Chehab
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

2009-12-02 Thread Jarod Wilson
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

2009-12-02 Thread Trent Piepho
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

2009-12-02 Thread Mauro Carvalho Chehab
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

2009-12-02 Thread Jarod Wilson
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

2009-12-02 Thread m-karicheri2
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

2009-12-02 Thread Karicheri, Muralidharan
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!

2009-12-02 Thread Michael Krufky
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

2009-12-02 Thread Jon Smirl
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

2009-12-02 Thread Andy Walls
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

2009-12-02 Thread 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.

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

2009-12-02 Thread Mauro Carvalho Chehab
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

2009-12-02 Thread hermann pitton

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

2009-12-02 Thread Trent Piepho
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

2009-12-02 Thread Jarod Wilson
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?

2009-12-02 Thread Jarod Wilson
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

2009-12-02 Thread Hans Verkuil
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

2009-12-02 Thread Hans Verkuil
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

2009-12-02 Thread Jon Smirl
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

2009-12-02 Thread Jon Smirl
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

2009-12-02 Thread Sean

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

2009-12-02 Thread Hiremath, Vaibhav

 -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

2009-12-02 Thread Hans de Goede

+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