Re: [RFC v2] Another approach to IR

2009-12-04 Thread Ferenc Wagner
Dmitry Torokhov dmitry.torok...@gmail.com writes:

 On Thu, Dec 03, 2009 at 02:33:56PM -0200, Mauro Carvalho Chehab wrote:
 Ferenc Wagner wrote:
 Mauro Carvalho Chehab mche...@redhat.com writes:
 
 We should not forget that simple IR's don't have any key to select the 
 address,
 so the produced codes there will never have KEY_TV/KEY_DVD, etc.

 Wait, wait, KEY_TV, KEY_DVD, KEY_TAPE - they should be used to select
 media inputs in a device/application. My receiver accepts codes like
 that.

Sorry, my point wasn't the event names, I picked them for their
superficial correspondence to the TV, DVD, SAT etc. buttons found on
multifunction remotes.  Obviously I picked wrong.

I was also wrong to assume that remotes with such buttons are always
multifunction remotes in the sense that they are meant to control
separate devices.  As Mauro pointed out, (some) bundled remotes with
such buttons aren't; thus I wouldn't consider them multifunction at all.
They simply have some extra buttons labelled TV, DVD etc, which probably
shouldn't be mapped to KEY_TV, KEY_DVD etc. (since those events carry
different semantics) but should be mapped to something else.  Or not, if
these buttons change some internal decoder state instead, modifying the
mapping or destination input device of the other keys.

It's just a different scenario, where the kernel could reasonably give
rather different representations to simple applications aiming at
plugplay: letting through the function change events untouched, or
masking and using them internally.

True multifunction devices don't send such events, the TV, DVD etc
buttons on them change their internal state and the scan codes sent by
the other keys, if I understand this correctly.

I'd prefer if these two behaviours could be abstacted from, and the
input layer interface would provide destination selection events +
generic events, or (to be defined) device specific events only in either
case.  Is that possible or even reasonable?
-- 
Thanks,
Feri.

Ps: I'm writing this in the hope to clean up the landscape and possibly
help in choosing the best design.  I'm not at all familiar with IR, and
the above distinction was pretty surprising for me.  Also, I'm just
lurking here, so don't take me too seriously. :)
--
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-03 Thread Mauro Carvalho Chehab
Andy Walls wrote:
 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.

Maybe you're having a bad time because you may be trying to integrate lirc
at the wrong place.

All devices at V4L tree including ir-kbd-i2c use ir-common.ko 
(at /drivers/media/common tree) module to communicate to IR's. 
I'm preparing some patches to extend this also to dvb-usb devices 
(that uses a close enough infrastructure). 

Also, most of the decoding code are there, in a form of helper routines.

As the idea is to provide lirc interface to all devices that can work with
raw pulse/space, the proper place is to write a subroutine there that, once
called, will make those pulse/space raw codes available to lirc and will
call the needed decoders to export them also to evdev.

The code at ir-common module was originally built to be used by V4L, but I'm
porting the code there to be generic enough to be a library that can be used
by other drivers. So, lirc_zilog and other lirc devices that will need to open
evdev interfaces after running a decoder can use them.

Due to that, we shouldn't add v4l2_subdevice there. Nothing prevents to create
a v4l2-ir-subdev glue if you want to see the IR's as subdevices, but this should
be implemented as a separate module.

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-03 Thread Mauro Carvalho Chehab
Andy Walls wrote:
 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.

The better is to add the lirc glue at ir-common module. There, we have the 
support
functions used by all V4L devices, and they'll be expanded to cover also
dvb-usb, as soon as I can find some time to do a patch for it.

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-03 Thread Mauro Carvalho Chehab
Jon Smirl wrote:
 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.

Currently, there aren't any in-kernel driver that support 64 bit IR's.
They support only up to 16 bits. So, we have only address (device)/command. 
As I said before, AFAIK, only RC6 mode 6 remotes support 64 bits. 

As pointed by Andy, it is risky to support such protocol in kernel,
since you won't be able to ship the kernel to countries where RC6 patents 
got accepted, or you would need.

 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. 

With hardware decoders, you're limited to the supported protocols, but yet,
you can use a different scancode than the one that comes with the shipped
device.

If you take a look, for example, at the NEC protocol decoder we have on
drivers/media/video/saa7134/saa7134-input.c [1], you'll see that the
tasklet (nec_task) holds CPU control up to 76.5 ms, in order to be able
to receive the entire sequence at the GPIO port. Fortunately, on the device
where this decoder is called (Avermedia M135A), we can trigger the start
of the IR code via IRQ.

[1]http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-2.6.git;a=blob;f=drivers/media/video/saa7134/saa7134-input.c;h=6e219c2db8419013ab3ced30470ad1c19431974a;hb=HEAD


In this specific decoder I've implemented it some time ago. I think
I tried first to get the pulse/space width using just IRQ without the tasklet,
but the lengths weren't precise enough for decoding. Also, if you have a bad
contact at the IR sensor connector, as it is directly connected to an IRQ pin,
you may end by hanging the machine, if the code is not carefully written.

I remember I had some bad time due to the bad contacts at the IR sensor
with the sample I had available 

Re: [RFC v2] Another approach to IR

2009-12-03 Thread Mauro Carvalho Chehab
Jon Smirl wrote:
 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.

This usecase makes sense to me.

With the risk of repeating myself, you don't have two physical remotes.
The needed feature is a way to split one source of input events (that
happens to be an infrared remote, but it could also be any other type of input
device, like a bluetooth remote) into several different evdev interfaces,
based on scancode groups. 

Also, as you're thinking on 64 bits scancodes, this also means that the
current evdev KABI and API will require changes to support bigger scancodes.

Anyway, IMO, this subject should be handled as a different requirement than
integrating the lirc drivers.

Cheers,
Mauro.
--
To unsubscribe from this list: 

Re: [RFC v2] Another approach to IR

2009-12-03 Thread Andy Walls
On Thu, 2009-12-03 at 08:00 -0200, Mauro Carvalho Chehab wrote:
 Andy Walls wrote:
  On Wed, 2009-12-02 at 14:55 -0500, Jarod Wilson wrote:
  On Dec 2, 2009, at 2:33 PM, Mauro Carvalho Chehab wrote:

 
  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.
 
 Maybe you're having a bad time because you may be trying to integrate lirc
 at the wrong place.

These were just ideas.  I haven't done *anything* yet. ;)


 All devices at V4L tree including ir-kbd-i2c use ir-common.ko 
 (at /drivers/media/common tree) module to communicate to IR's. 
 I'm preparing some patches to extend this also to dvb-usb devices 
 (that uses a close enough infrastructure). 
 
 Also, most of the decoding code are there, in a form of helper routines.
 
 As the idea is to provide lirc interface to all devices that can work with
 raw pulse/space, the proper place is to write a subroutine there that, once
 called, will make those pulse/space raw codes available to lirc and will
 call the needed decoders to export them also to evdev.
 
 The code at ir-common module was originally built to be used by V4L, but I'm
 porting the code there to be generic enough to be a library that can be used
 by other drivers. So, lirc_zilog and other lirc devices that will need to open
 evdev interfaces after running a decoder can use them.

I think I see what you are saying (I wish could see look at a whiteboard
somewhere...).  Wherever we come through internally to split to 2
different userspace interfaces is fine, if you've got a big picture plan
you think is feasible.

That seems like a bit of perturbation to lirc_zilog and lirc_i2c.  My
thought was that lirc_v4l using the standardized v4l2_subdev_ir_ops
interface, and maybe some new calls associted with v4l2_device, could
subsume/unify all the functionality of lirc_i2c, lirc_zilog, ...
lirc_whatever.

Maybe that's just a poorly thought out dream though...


 Due to that, we shouldn't add v4l2_subdevice there. Nothing prevents to create
 a v4l2-ir-subdev glue if you want to see the IR's as subdevices, but this 
 should
 be implemented as a separate module.

The v4l_subdevice just abstracted the IR hardware into a nice (mental)
box for me -- easier to keep hardware separate from software decoders
and userspace interface logic.

Also, since v4l2_subdevices may have per subdevice /dev nodes and
the /dev/../mcN nodes providing a discovery mechanism due to the Meda
Controller framework, wrapping things in v4l2_subdevice may be handy for
development and debug.  Or ... as an additional operational interface to
userspace. :D  *ducks and runs for cover*

Regards,
Andy

 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-03 Thread Ferenc Wagner
Mauro Carvalho Chehab mche...@redhat.com writes:

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

 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.

The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT,
KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent
by any remote (ok, I'm stretching it a bit).  Instead, a multifunction
remote (or two distinct remotes) would send different scan codes[1],
which should be mapped to KEY_PLAYCD and KEY_PLAYDVD for example.
Btw. the former is already defined, besides the generic KEY_PLAY.

Even if all this worked, user space would need integration with
hal/devicekit to open the new input devices appearing on the fly (if
it's initiated by the arrival of a scan code belonging to some new
protocol), and also be able to decide whether the new event source is
for it or not.

Given that commodity home appliances manage not to be confused by
multiple or multifunction remotes, decent software should be able to do
so as well.

[1] scan codes in the broadest possible sense, containing vendor,
address and whatever, and only treating the case which is possible to
handle in principle.
-- 
Regards,
Feri.
--
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-03 Thread Mauro Carvalho Chehab
Ferenc Wagner wrote:
 Mauro Carvalho Chehab mche...@redhat.com writes:
 
 Dmitry Torokhov wrote:


 The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT,
 KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent
 by any remote (ok, I'm stretching it a bit). 

Unfortunately, this is not true. Some IR's do send a keycode for TV/PC/SAT/CD, 
etc.

On those remotes, if you press TV and then press for example Channel UP
and press Radio, then press Channel UP, the channel UP code will be the same.

For example, on Hauppauge Grey IR, we have:

TV
[13425.128525] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e1c 
keycode 0x179
[13425.136733] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 
down=1
[13425.144170] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 
down=0

CHANNEL UP
[13428.350223] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 
keycode 0x192
[13428.358434] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 
down=1
[13428.365871] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 
down=0

Radio
[13430.672266] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e0c 
keycode 0x181
[13430.680473] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 
down=1
[13430.687913] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 
down=0

CHANNEL UP
[13433.697268] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 
keycode 0x192
[13433.705480] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 
down=1
[13433.712916] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 
down=0

In this IR, the address is bogus: it is always 0x1e. This scenario is very 
common with the
shipped IR's.

 Instead, a multifunction
 remote (or two distinct remotes) would send different scan codes[1],
 which should be mapped to KEY_PLAYCD and KEY_PLAYDVD for example.
 Btw. the former is already defined, besides the generic KEY_PLAY.
 
 Even if all this worked, user space would need integration with
 hal/devicekit to open the new input devices appearing on the fly (if
 it's initiated by the arrival of a scan code belonging to some new
 protocol), and also be able to decide whether the new event source is
 for it or not.
 
 Given that commodity home appliances manage not to be confused by
 multiple or multifunction remotes, decent software should be able to do
 so as well.
 
 [1] scan codes in the broadest possible sense, containing vendor,
 address and whatever, and only treating the case which is possible to
 handle in principle.

I see two alternatives for it:
1) to map a multifunction scancode Address=TV/command=channel up as two
separate events: KEY_TV | KEY_CHANNELUP and let some userspace program to
handle it (lirc or other programs that knows IR keycodes);

2) to implement Jon's filter idea of splitting one evdev interface into
several evdevs interface, one for each address.

We should not forget that simple IR's don't have any key to select the address,
so the produced codes there will never have KEY_TV/KEY_DVD, etc.

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-03 Thread Jon Smirl
On Thu, Dec 3, 2009 at 11:33 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Ferenc Wagner wrote:
 Mauro Carvalho Chehab mche...@redhat.com writes:

 Dmitry Torokhov wrote:


 The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT,
 KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent
 by any remote (ok, I'm stretching it a bit).

 Unfortunately, this is not true. Some IR's do send a keycode for 
 TV/PC/SAT/CD, etc.

 On those remotes, if you press TV and then press for example Channel UP
 and press Radio, then press Channel UP, the channel UP code will be the same.

 For example, on Hauppauge Grey IR, we have:

 TV
 [13425.128525] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 
 0x1e1c keycode 0x179
 [13425.136733] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 
 down=1
 [13425.144170] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 
 down=0

 CHANNEL UP
 [13428.350223] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 
 0x1e20 keycode 0x192
 [13428.358434] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 
 down=1
 [13428.365871] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 
 down=0

 Radio
 [13430.672266] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 
 0x1e0c keycode 0x181
 [13430.680473] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 
 down=1
 [13430.687913] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 
 down=0

 CHANNEL UP
 [13433.697268] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 
 0x1e20 keycode 0x192
 [13433.705480] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 
 down=1
 [13433.712916] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 
 down=0

 In this IR, the address is bogus: it is always 0x1e. This scenario is very 
 common with the
 shipped IR's.

The remote is treating everything as a single integrated device which
is not inconsistent with what has been said. In this case there really
is only one multi-function device not two independent ones.

If you want to control two independent devices you need to buy a
different remote. Remotes are cheap so that's not a big deal.

If you really want to use this remote to control two independent
devices you need user space scripting to split the single device into
two devices and then inject new events into the input layer. This is a
complex case and not in the goal of getting 90% of users to just
work.


 Instead, a multifunction
 remote (or two distinct remotes) would send different scan codes[1],
 which should be mapped to KEY_PLAYCD and KEY_PLAYDVD for example.
 Btw. the former is already defined, besides the generic KEY_PLAY.

 Even if all this worked, user space would need integration with
 hal/devicekit to open the new input devices appearing on the fly (if
 it's initiated by the arrival of a scan code belonging to some new
 protocol), and also be able to decide whether the new event source is
 for it or not.

 Given that commodity home appliances manage not to be confused by
 multiple or multifunction remotes, decent software should be able to do
 so as well.

 [1] scan codes in the broadest possible sense, containing vendor,
 address and whatever, and only treating the case which is possible to
 handle in principle.

 I see two alternatives for it:
        1) to map a multifunction scancode Address=TV/command=channel up as two
 separate events: KEY_TV | KEY_CHANNELUP and let some userspace program to
 handle it (lirc or other programs that knows IR keycodes);

        2) to implement Jon's filter idea of splitting one evdev interface into
 several evdevs interface, one for each address.

 We should not forget that simple IR's don't have any key to select the 
 address,
 so the produced codes there will never have KEY_TV/KEY_DVD, etc.

 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-03 Thread Emmanuel Fusté

Jon Smirl wrote:
 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.

This usecase makes sense to me.

With the risk of repeating myself, you don't have two physical remotes.
The needed feature is a way to split one source of input events (that
happens to be an infrared remote, but it could also be any other type of input
device, like a bluetooth remote) into several different evdev interfaces,
based on scancode groups. 


In real world you generally have two physical remote. In this particular case 
you simply have a sort of semi-universal remote, a two or tree in one remote.
More particularly, you have a remote which is aimed at talking to two or tree different 
real devices or in our case different applications. If the application 

Re: [RFC v2] Another approach to IR

2009-12-03 Thread Dmitry Torokhov
On Thu, Dec 03, 2009 at 02:33:56PM -0200, Mauro Carvalho Chehab wrote:
 Ferenc Wagner wrote:
  Mauro Carvalho Chehab mche...@redhat.com writes:
 
 We should not forget that simple IR's don't have any key to select the 
 address,
 so the produced codes there will never have KEY_TV/KEY_DVD, etc.

Wait, wait, KEY_TV, KEY_DVD, KEY_TAPE - they should be used to select
media inputs in a device/application. My receiver accepts codees like
that.

-- 
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-03 Thread Emmanuel Fusté


Em Thu, 3 Dec 2009 11:50:04 -0500
Jon Smirl jonsm...@gmail.com escreveu:

 On Thu, Dec 3, 2009 at 11:33 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
  Ferenc Wagner wrote:
  Mauro Carvalho Chehab mche...@redhat.com writes:
 
  Dmitry Torokhov wrote:
 
 
  The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT,
  KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent
  by any remote (ok, I'm stretching it a bit).
 
  Unfortunately, this is not true. Some IR's do send a keycode for 
TV/PC/SAT/CD, etc.
 
  On those remotes, if you press TV and then press for example Channel UP
  and press Radio, then press Channel UP, the channel UP code will be the 
same.
 
  For example, on Hauppauge Grey IR, we have:
 
  TV
  [13425.128525] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 
0x1e1c keycode 0x179
  [13425.136733] ir_input_key_event: em28xx IR (em28xx #0): key event 
code=377 down=1
  [13425.144170] ir_input_key_event: em28xx IR (em28xx #0): key event 
code=377 down=0
 
  CHANNEL UP
  [13428.350223] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 
0x1e20 keycode 0x192
  [13428.358434] ir_input_key_event: em28xx IR (em28xx #0): key event 
code=402 down=1
  [13428.365871] ir_input_key_event: em28xx IR (em28xx #0): key event 
code=402 down=0
 
  Radio
  [13430.672266] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 
0x1e0c keycode 0x181
  [13430.680473] ir_input_key_event: em28xx IR (em28xx #0): key event 
code=385 down=1
  [13430.687913] ir_input_key_event: em28xx IR (em28xx #0): key event 
code=385 down=0
 
  CHANNEL UP
  [13433.697268] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 
0x1e20 keycode 0x192
  [13433.705480] ir_input_key_event: em28xx IR (em28xx #0): key event 
code=402 down=1
  [13433.712916] ir_input_key_event: em28xx IR (em28xx #0): key event 
code=402 down=0
 
  In this IR, the address is bogus: it is always 0x1e. This scenario is very 
common with the
  shipped IR's.
 
 The remote is treating everything as a single integrated device which

 is not inconsistent with what has been said. In this case there really
 is only one multi-function device not two independent ones.
 
 If you want to control two independent devices you need to buy a

 different remote. Remotes are cheap so that's not a big deal.
 
 If you really want to use this remote to control two independent

 devices you need user space scripting to split the single device into
 two devices and then inject new events into the input layer. This is a
 complex case and not in the goal of getting 90% of users to just
 work.

This remote is a typical example of the IR's that are provided together with 
media boards.
On all such IR's I know, it does generate one key event for TV, SAT, DVB, 
DVD... keys and
this event doesn't change the status of subsequent keys.

100% of the users of such boards will have the shipped IR. Some amount will be 
happy of
just using the provided IR to control different applications at their computer 
or embedded
hardware, and some amount will prefer to buy a multi-purpose IR that will allow 
him
to control not only his computer, but also, his TV, his Air conditioning, etc.

Both usages should be supported.

All I'm saying is that, in the case where people have only the shipped IR, if 
he wants to
see TV, the produced keycode will be KEY_TV, and then to change a channel, it 
will
receive KEY_CHANNELUP, to control his TV app. When the user decides to switch to DVB, 
he will press KEY_DVB and then KEY_PLAY to play his movie.


So, an application like MythTV should be able to work with those keys.
  

Eeeerrrkkk, what a .. device .
For such quirky device, we could imagine a special mapping support:
We could maps scancode 0x1e1c and 0x1e0c special keycode wich inform the 
input layer to surcharge the  vendor or device with a specific 
value/mask for following  keypresses of such remote. The mask could be 
choose to generate out of bound value in regards of the used protocol 
for the vendor or the device part to not overlap with another existing 
remote.
Generate a complete map and so a device for each special key and you're 
done. No special case on the application side.
In kernel states are a bit ugly, but this particular case is not too 
complicated and your dumb shitty remote is promoted to first class one.



Regards,
Emmanuel.


--
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-03 Thread Emmanuel Fusté


On Thu, Dec 03, 2009 at 02:33:56PM -0200, Mauro Carvalho Chehab wrote:
 Ferenc Wagner wrote:
  Mauro Carvalho Chehab mche...@redhat.com writes:
 
 We should not forget that simple IR's don't have any key to select the address,

 so the produced codes there will never have KEY_TV/KEY_DVD, etc.

Wait, wait, KEY_TV, KEY_DVD, KEY_TAPE - they should be used to select
media inputs in a device/application. My receiver accepts codees like
that.
  

Yes, it seem that there is confusion here.
Forget my proposition. It is a corner case that could be handled later 
if needed.



Cheers,
Emmanuel.
--
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-03 Thread Krzysztof Halasa
Jarod Wilson ja...@wilsonet.com writes:

 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?

We don't want this, and we aren't really able to do this, because we
never know if two different scan codes are part of the same or different
command set.

Sharing the protocol and e.g. group code doesn't mean it's the same
remote.

Different protocol doesn't mean it's a different remote and what's more
important, doesn't mean the user wants it to be a different logical
remote.
-- 
Krzysztof Halasa
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC v2] Another approach to IR

2009-12-03 Thread Krzysztof Halasa
Mauro Carvalho Chehab mche...@redhat.com writes:

 Btw, looking at that code, while it is not impossible to split the 
 IR pulse/space measures from the NEC decoder itself, and make it generic
 to support other protocols, it is not a trivial task, and may result on
 a less stable driver.

And it's not needed at all.
Protocol decoders can be easily run in parallel, I've done it on saa713x
and this is trivial at least there. Can do that when the lirc interface
is available.

 The advantage of the NEC decoding approach on saa7134 is that you know for
 sure how much time it is required to get the entire code. So, the code 
 can easily abort the reception of a bad code. The disadvantage is that 
 only one protocol can be decoded at the same time.

This isn't a hard thing to fix.

 The same problem also happens with almost all in-kernel drivers: the decoders
 for raw mode were constructed to work with just one pulse/space code at the
 same time. A conversion into a generic code can happen, but it will require
 several tests to be sure that they won't cause undesirable side-effects.

IOW any such receiver has to be tested, sure.

 The advantage of hardware decoders is that you don't need to be polling the
 IR serial port at a high rate, as you'll get directly the code. So, you'll
 free the CPU to do something else.

Which device requires polling the port?
Most are IRQ-driven, aren't they?
-- 
Krzysztof Halasa
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC v2] Another approach to IR

2009-12-03 Thread alhaz

Quoting Jon Smirl jonsm...@gmail.com:


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


From a hobbiest's perspective there's likely rarely any reason to be  
able to do the same thing with two different remotes that send  
different signals, but i could see it come up - For example if you  
wanted to have both a feature-rich,  busy/complicated remote but also  
wanted to provide a simpler remote with a relatively small number of  
large buttons on it for basic functions, as for children or people  
with poor eyesight or poor motor control.


From a business perspective, I've worked for a company that sold  
turn-key video training systems, and depending on the whims of our  
so-called business partners and the desires of customers, there were  
as many as three distinct remotes that might get shipped with the  
training system, and they all sent different signals.


That was a less than ideal situation, and if we had been really on top  
of things we'd have just declined to use any of those remotes and  
bought custom remotes from any of the numerous vendors that sell them  
which would allow us to have one set of IR signals used by remotes  
with different features - but for whatever reason that wasn't how  
management decided to do things.

--
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-03 Thread Mauro Carvalho Chehab
Krzysztof Halasa wrote:
 Mauro Carvalho Chehab mche...@redhat.com writes:
 
 Btw, looking at that code, while it is not impossible to split the 
 IR pulse/space measures from the NEC decoder itself, and make it generic
 to support other protocols, it is not a trivial task, and may result on
 a less stable driver.
 
 And it's not needed at all.
 Protocol decoders can be easily run in parallel, I've done it on saa713x
 and this is trivial at least there. Can do that when the lirc interface
 is available.

 The advantage of the NEC decoding approach on saa7134 is that you know for
 sure how much time it is required to get the entire code. So, the code 
 can easily abort the reception of a bad code. The disadvantage is that 
 only one protocol can be decoded at the same time.
 
 This isn't a hard thing to fix.

Good to know. We're open to patches to improve it. 

The point is that we've got in the past several complains about saa713x
machines hanging due to IRQ's generated by IR sensor port. We ended by adding
an option to disable IR and a code at the driver that disables IR IRQ if it 
happens too often.

 
 The same problem also happens with almost all in-kernel drivers: the decoders
 for raw mode were constructed to work with just one pulse/space code at the
 same time. A conversion into a generic code can happen, but it will require
 several tests to be sure that they won't cause undesirable side-effects.
 
 IOW any such receiver has to be tested, sure.
 
 The advantage of hardware decoders is that you don't need to be polling the
 IR serial port at a high rate, as you'll get directly the code. So, you'll
 free the CPU to do something else.
 
 Which device requires polling the port?
 Most are IRQ-driven, aren't they?

Most of the devices that have a hardware IR decodes needs polling. Most of they
simply outputs the scan code on some set of GPIO pins.

In general, the devices with the IR sensor connected to a GPIO pin are 
IRQ-driven.

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 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: [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: [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: [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


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


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

2009-12-01 Thread Maxim Levitsky
On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote: 
 While reading all of these IR threads another way of handling IR
 occurred to me that pretty much eliminates the need for LIRC and
 configuration files in default cases. The best way to make everything
 just work is to eliminate it.
 
 The first observation is that the IR profile of various devices are
 well known. Most devices profiles are in the published One-for-All
 database. These device profiles consist of vendor/device/command
 triplets. There is one triplet for each command like play, pause, 1,
 2, 3, power, etc.
 
 The second observation is that universal remotes know how to generate
 commands for all of the common devices.
 
 Let's define evdev messages for IR than contain vendor/device/command
 triplets. I already posted code for doing that in my original patch
 set. These messages are generated from in-kernel code.
 
 Now add a small amount of code to MythTV, etc to act on these evdev
 messages. Default MythTV, etc to respond to the IR commands for a
 common DVR device. Program your universal remote to send the commands
 for this device. You're done. Everything will just work - no LIRC,
 no irrecord, no config files, no command mapping, etc.
You are making one  big wrong assumption that everyone that has a remote
uses mythtv, and only it.

Many users including me, use the remote just like a keyboard, or even
like a mouse.


 
 Of course there are details involved in making this work. MythTV will
 have to have a config option to allow it to emulate several different
 DVR devices so that you can pick one that you don't own. It should
 also have choices for emulating the common devices defined for the
 remotes included with various Linux video board like the Hauppauge
 remote.
 
 For apps that haven't been modified you will have to run a daemon
 which will capture vendor/device/command evdev events and convert them
 into keystroke commands than work the menus. You'll need a config file
 for this and have to write scripts. Instead I'd just go modify the app
 the respond to the IR events, it is easy to do.
 
 Long run, we define a MythTV IR profile, mplayer profile, etc and get
 these into the IR database for universal remotes. Now MythTV can stop
 emulating another vendor's device.
 
 For the default MythTV case no external support will need to be
 installed if the protocol decode engines are in the kernel. The raw
 data will come in, run through the engines, and pop out as evdev
 messages with a vendor/device/command triplet. Devices that decode in
 hardware will just send vendor/device/command triplets.
 


--
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-01 Thread Jon Smirl
On Tue, Dec 1, 2009 at 10:47 AM, Maxim Levitsky maximlevit...@gmail.com wrote:
 On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote:
 While reading all of these IR threads another way of handling IR
 occurred to me that pretty much eliminates the need for LIRC and
 configuration files in default cases. The best way to make everything
 just work is to eliminate it.

 The first observation is that the IR profile of various devices are
 well known. Most devices profiles are in the published One-for-All
 database. These device profiles consist of vendor/device/command
 triplets. There is one triplet for each command like play, pause, 1,
 2, 3, power, etc.

 The second observation is that universal remotes know how to generate
 commands for all of the common devices.

 Let's define evdev messages for IR than contain vendor/device/command
 triplets. I already posted code for doing that in my original patch
 set. These messages are generated from in-kernel code.

 Now add a small amount of code to MythTV, etc to act on these evdev
 messages. Default MythTV, etc to respond to the IR commands for a
 common DVR device. Program your universal remote to send the commands
 for this device. You're done. Everything will just work - no LIRC,
 no irrecord, no config files, no command mapping, etc.
 You are making one  big wrong assumption that everyone that has a remote
 uses mythtv, and only it.

 Many users including me, use the remote just like a keyboard, or even
 like a mouse.

So let's try and figure out a just works scheme for doing this. What
I'm trying to do is to get everyone to step back and think about this
problem instead of rushing head long into merging LIRC as is. irrecord
is not something a non-technical user can easily handle.

A basic scheme that can be used to eliminate configuration is to take
well known IR device profiles and emulate them in Linux.  So pick
another well known device to emulate (call it A) and map it to
mouse/keyboard events.  Mapping vendor/device/command codes for a
couple devices to mouse/keyboard events is a tiny amount of data and
can be done in-kernel.

This case could also be made to just work. Set your universal remote
to device A. Commands from for device A will arrive and be mapped into
generic keyboard/mouse commands.

There are probably other solutions to making IR work without needing
irrecord and configuration. What would be some other possibilities?

Also consider the long term strategy of defining standard device
profiles and getting them into the IR database. Make an IR profile for
mouse/keyboard. After this gets into the database a universal remote
can be set to this profile which will be a better match than emulating
another device.





 Of course there are details involved in making this work. MythTV will
 have to have a config option to allow it to emulate several different
 DVR devices so that you can pick one that you don't own. It should
 also have choices for emulating the common devices defined for the
 remotes included with various Linux video board like the Hauppauge
 remote.

 For apps that haven't been modified you will have to run a daemon
 which will capture vendor/device/command evdev events and convert them
 into keystroke commands than work the menus. You'll need a config file
 for this and have to write scripts. Instead I'd just go modify the app
 the respond to the IR events, it is easy to do.

 Long run, we define a MythTV IR profile, mplayer profile, etc and get
 these into the IR database for universal remotes. Now MythTV can stop
 emulating another vendor's device.

 For the default MythTV case no external support will need to be
 installed if the protocol decode engines are in the kernel. The raw
 data will come in, run through the engines, and pop out as evdev
 messages with a vendor/device/command triplet. Devices that decode in
 hardware will just send vendor/device/command triplets.







-- 
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-01 Thread Mauro Carvalho Chehab
Hi Jon,

Jon Smirl wrote:
 On Tue, Dec 1, 2009 at 10:47 AM, Maxim Levitsky maximlevit...@gmail.com 
 wrote:
 On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote:
 While reading all of these IR threads another way of handling IR
 occurred to me that pretty much eliminates the need for LIRC and
 configuration files in default cases. The best way to make everything
 just work is to eliminate it.

 The first observation is that the IR profile of various devices are
 well known. Most devices profiles are in the published One-for-All
 database. These device profiles consist of vendor/device/command
 triplets. There is one triplet for each command like play, pause, 1,
 2, 3, power, etc.

 The second observation is that universal remotes know how to generate
 commands for all of the common devices.

 Let's define evdev messages for IR than contain vendor/device/command
 triplets. I already posted code for doing that in my original patch
 set. These messages are generated from in-kernel code.

 Now add a small amount of code to MythTV, etc to act on these evdev
 messages. Default MythTV, etc to respond to the IR commands for a
 common DVR device. Program your universal remote to send the commands
 for this device. You're done. Everything will just work - no LIRC,
 no irrecord, no config files, no command mapping, etc.
 You are making one  big wrong assumption that everyone that has a remote
 uses mythtv, and only it.

 Many users including me, use the remote just like a keyboard, or even
 like a mouse.
 
 So let's try and figure out a just works scheme for doing this. What
 I'm trying to do is to get everyone to step back and think about this
 problem instead of rushing head long into merging LIRC as is. irrecord
 is not something a non-technical user can easily handle.
 
 A basic scheme that can be used to eliminate configuration is to take
 well known IR device profiles and emulate them in Linux.  So pick
 another well known device to emulate (call it A) and map it to
 mouse/keyboard events.  Mapping vendor/device/command codes for a
 couple devices to mouse/keyboard events is a tiny amount of data and
 can be done in-kernel.
 
 This case could also be made to just work. Set your universal remote
 to device A. Commands from for device A will arrive and be mapped into
 generic keyboard/mouse commands.
 
 There are probably other solutions to making IR work without needing
 irrecord and configuration. What would be some other possibilities?
 
 Also consider the long term strategy of defining standard device
 profiles and getting them into the IR database. Make an IR profile for
 mouse/keyboard. After this gets into the database a universal remote
 can be set to this profile which will be a better match than emulating
 another device.

This is basically the way the current in-kernel IR drivers work. The
driver converts scancodes (device address/command sequence) into
an evdev standard code.

Just taking an example from the dibcom0700 driver (as the same driver 
supports several different RC5 and NEC codes at the same time), 
the kernel table has several keycodes added there, all working
at the same time. Providing that the scancodes won't overlap, you can
map two different scancodes (from different IR's) to return the same
keycode (table is not complete - I just got a few common keycodes):

# SCAN Key_code
#
0xeb13 KEY_RIGHT
0x1e17 KEY_RIGHT
0x1d17 KEY_RIGHT
0x860f KEY_RIGHT

0xeb11 KEY_LEFT
0x1e16 KEY_LEFT
0x1d16 KEY_LEFT
0x860e KEY_LEFT

0x0703 KEY_VOLUMEUP
0xeb1c KEY_VOLUMEUP
0x1e10 KEY_VOLUMEUP
0x037d KEY_VOLUMEUP
0x1d10 KEY_VOLUMEUP
0x8610 KEY_VOLUMEUP
0x7a12 KEY_VOLUMEUP

0x0709 KEY_VOLUMEDOWN
0xeb1e KEY_VOLUMEDOWN
0x1e11 KEY_VOLUMEDOWN
0x017d KEY_VOLUMEDOWN
0x1d11 KEY_VOLUMEDOWN
0x860c KEY_VOLUMEDOWN
0x7a13 KEY_VOLUMEDOWN

0x0706 KEY_CHANNELUP
0xeb1b KEY_CHANNELUP
0x1e20 KEY_CHANNELUP
0x0242 KEY_CHANNELUP
0x1d20 KEY_CHANNELUP
0x860d KEY_CHANNELUP
0x7a10 KEY_CHANNELUP

0x070c KEY_CHANNELDOWN
0xeb1f KEY_CHANNELDOWN
0x1e21 KEY_CHANNELDOWN
0x007d KEY_CHANNELDOWN
0x1d21 KEY_CHANNELDOWN
0x8619 KEY_CHANNELDOWN
0x7a11 KEY_CHANNELDOWN

It should be noticed, however, that some devices may be provided with a shipped
IR with a different keytable where the keycodes may overlap with this table.

So, what we can do is to have a default keycode table mapping several
different IR's there to be used by drivers that are shipped with an IR
that can be fully mapped by the default table. However, for devices
with scancodes that overlaps with the default table, we'll need a separate
table.

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-01 Thread Devin Heitmueller
On Tue, Dec 1, 2009 at 12:03 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Just taking an example from the dibcom0700 driver (as the same driver
 supports several different RC5 and NEC codes at the same time),
 the kernel table has several keycodes added there, all working
 at the same time. Providing that the scancodes won't overlap, you can
 map two different scancodes (from different IR's) to return the same
 keycode (table is not complete - I just got a few common keycodes):

Mauro,

Just to be clear, the dib0700 does not actually support receiving RC5
or NEC codes at the same time.  You have to tell the chip which mode
to operate in, via a REQUEST_SET_RC to the firmware (see
dib0700_core.c:405).  The em28xx works the same way (you have to tell
it what type of IR format to receive).

The fact that the driver currently uses the same lookup table for both
types of remote controls however, was perhaps not the best design
choice.  It really should be separated out, and merged with the
regular ir-functions.c.  I just never got around to it.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC v2] Another approach to IR

2009-12-01 Thread Patrick Boettcher

Hi,
On Tue, 1 Dec 2009, Devin Heitmueller wrote:


On Tue, Dec 1, 2009 at 12:03 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:

Just taking an example from the dibcom0700 driver (as the same driver
supports several different RC5 and NEC codes at the same time),
the kernel table has several keycodes added there, all working
at the same time. Providing that the scancodes won't overlap, you can
map two different scancodes (from different IR's) to return the same
keycode (table is not complete - I just got a few common keycodes):


Mauro,

Just to be clear, the dib0700 does not actually support receiving RC5
or NEC codes at the same time.  You have to tell the chip which mode
to operate in, via a REQUEST_SET_RC to the firmware (see
dib0700_core.c:405).  The em28xx works the same way (you have to tell
it what type of IR format to receive).

The fact that the driver currently uses the same lookup table for both
types of remote controls however, was perhaps not the best design
choice.  It really should be separated out, and merged with the
regular ir-functions.c.  I just never got around to it.


I did not follow all the discussion, still I have a comment:

I will soon work on a device where it is the driver who is doing the 
decoding of the IR-frames. It is (maybe, I'm still missing some pieces to 
be sure) possible to receive different protocols at the same time with 
this hardware.


--

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


Re: [RFC v2] Another approach to IR

2009-12-01 Thread Mauro Carvalho Chehab
Maxim Levitsky wrote:
 On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote: 
 While reading all of these IR threads another way of handling IR
 occurred to me that pretty much eliminates the need for LIRC and
 configuration files in default cases. The best way to make everything
 just work is to eliminate it.

 The first observation is that the IR profile of various devices are
 well known. Most devices profiles are in the published One-for-All
 database. These device profiles consist of vendor/device/command
 triplets. There is one triplet for each command like play, pause, 1,
 2, 3, power, etc.

 The second observation is that universal remotes know how to generate
 commands for all of the common devices.

 Let's define evdev messages for IR than contain vendor/device/command
 triplets. I already posted code for doing that in my original patch
 set. These messages are generated from in-kernel code.

 Now add a small amount of code to MythTV, etc to act on these evdev
 messages. Default MythTV, etc to respond to the IR commands for a
 common DVR device. Program your universal remote to send the commands
 for this device. You're done. Everything will just work - no LIRC,
 no irrecord, no config files, no command mapping, etc.
 You are making one  big wrong assumption that everyone that has a remote
 uses mythtv, and only it.
 
 Many users including me, use the remote just like a keyboard, or even
 like a mouse.

+1. 

I also use the remote as a keyboard replacement. I used an IR like
that for a long time while teaching, using a standard USB video board,
as a way to remotely control my notebook.

Well, now I have an USB IR for this usage, using HID, that emulates
both keyboard and mouse. In fact, the application didn't change. 
I'm just using the standard USB class for HID, instead of using
vendor class to generate the same kind of evdev events ;)

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-01 Thread Mauro Carvalho Chehab
Patrick Boettcher wrote:

 The fact that the driver currently uses the same lookup table for both
 types of remote controls however, was perhaps not the best design
 choice.  It really should be separated out, and merged with the
 regular ir-functions.c.  I just never got around to it.
 
 I did not follow all the discussion, still I have a comment:
 
 I will soon work on a device where it is the driver who is doing the
 decoding of the IR-frames. It is (maybe, I'm still missing some pieces
 to be sure) possible to receive different protocols at the same time
 with this hardware.

That's good news! Needing to pass a modprobe parameter to select the protocol
is not nice, and, while an ioctl will be needed to select IR protocols
(as there are some hardwares where this is not possible at all), the better
is to auto-detect the protocol.

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-01 Thread Jon Smirl
On Tue, Dec 1, 2009 at 2:00 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Due to the lack of an API for it, each driver has their own way to handle the
 protocols, but basically, on almost all drivers, even supporting different 
 protocols,
 the driver limits the usage of just the protocol provided by the shipped 
 remote.

 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.

evdev capabilities bits can support enumerating the supported
protocols. I'm not sure if you can write those bits back into evdev to
turn a feature off/on. If not its something that could be added to
evdev.

I agree that there is no consistency in the existing driver implementations.

-- 
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-01 Thread Dmitry Torokhov
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.

-- 
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-01 Thread Mauro Carvalho Chehab
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.

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?

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