Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-12 Thread david

On Mon, 23 Nov 2009, Krzysztof Halasa wrote:


Devin Heitmueller dheitmuel...@kernellabs.com writes:


There is an argument to be made that since it may be desirable for
both IR receivers and transmitters to share the same table of remote
control definitions, it might make sense to at least *consider* how
the IR transmitter interface is going to work, even if it is decided
to not implement such a design in the first revision.

Personally, I would hate to see a situation where we find out that we
took a bad approach because nobody considered what would be required
for IR transmitters to reuse the same remote control definition data.


I briefly though about such possibility, but dismissed it with
assumption that we won't transmit the same codes (including key codes)
that we receive.

Perhaps I'm wrong.


I could definantly see this happening. the computer receives the 'play' 
button from a dvd remote, issues commands to control the audio system, dim 
lights, and then sends the 'play' button to the DVD player inside a 
cabinet where it can't see the remote directly.


but in any case, it shouldn't be hard to share a table of mappings.

David Lang
--
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-08 Thread Mauro Carvalho Chehab
Andy Walls wrote:
 On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
 On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:

 On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
 Krzysztof Halasa wrote:
 Andy Walls awa...@radix.net writes:

 I would also note that RC-6 Mode 6A, used by most MCE remotes, was
 developed by Philips, but Microsoft has some sort of licensing interest
 in it and it is almost surely encumbered somwhow:
 I don't know about legal problems in some countries but from the
 technical POV handling the protocol in the kernel is more efficient
 or (/and) simpler.
 A software licensing from Microsoft won't apply to Linux kernel, so I'm
 assuming that you're referring to some patent that they could be filled
 about RC6 mode 6A.

 I don't know if is there any US patent pending about it (AFAIK, only US
 accepts software patents), but there are some prior-art for IR key
 decoding. So, I don't see what innovation RC6 would be adding. 
 If it is some new way to transmit waves, the patent issues
 aren't related to software, and the device manufacturer had already handled
 it when they made their devices.

 If it is just a new keytable, this issue 
 could be easily solved by loading the keytable via userspace.

 Also, assuming that you can use the driver only with a hardware that comes
 with a licensed software, the user has already the license for using it.

 Do you have any details on what patents they are claiming?
 The US Philips RC-6 patent is US Patent 5,877,702

 http://www.google.com/patents?vid=USPAT5877702

 Click on download PDF to get a copy of the whole patent.

 I am not a lawyer.  Philips claims' all appear to tie to a transmitter
 or receiver as part of a system, but most of the claims are about
 information and bit positions and lengths.
 ...
 IMO, given

 a. the dearth of public information about RC-6, indicating someone
 thinks it's their trade secret or intellectual property

 b. Microsoft claiming to license something related to the MCE remote
 protocols (which are obviously RC-6 Mode 6A),

 c. my inability to draw a clear, bright line that RC-6 Mode 6A
 encoding and decoding, as needed by MCE remotes, implemented in software
 doesn't violate anyone's government granted rights to exclusivity.

 I think it's much better to implement software RC-6 Mode 6A encoding and
 decoding in user space, doing only the minimum needed to get the
 hardware setup and going in the kernel.  

 Encoding/decoding of RC-6 by microcontrollers with firmware doesn't
 worry me. 


 Maybe I'm being too conservative here, but I have a personal interest in
 keeping Linux free and unencumbered even in the US which, I cannot deny,
 has a patent system that is screwed up.
 So I had one of the people who does all the license and patent audits
 for Fedora packages look at the Philips patent on RC-6. He's 100%
 positive that the patent *only* covers hardware, there should be no
 problem whatsoever writing a software decoder for RC-6.
 
 OK.  Thanks for having some professionals take a look.  (I'm assuming
 that's the only patent.)
 
 So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
 end of the month.

Good! Please, try to design the decoder as an independent module that gets
data from a kfifo and generate scancodes for the input API.
 
 I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
 a common set of parameters, so I may be able to set up the decoders to
 handle decoding from two different remote types at once.  The HVR boards
 can ship with either type of remote AFAIK.
 
 I wonder if I can flip the keytables on the fly or if I have to create
 two different input devices?

IMO, the better is, by default, to open just one input device per IR receiver.
From what I understand from our discussions, if the user wants to filter IR
commands into several input interfaces, some userspace interface will be 
provided to allow the creation of other input interfaces for that purpose.

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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-08 Thread Mauro Carvalho Chehab
Dmitry Torokhov wrote:
 On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
 On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
 On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:

 On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
 Krzysztof Halasa wrote:
 Andy Walls awa...@radix.net writes:

 I would also note that RC-6 Mode 6A, used by most MCE remotes, was
 developed by Philips, but Microsoft has some sort of licensing interest
 in it and it is almost surely encumbered somwhow:
 I don't know about legal problems in some countries but from the
 technical POV handling the protocol in the kernel is more efficient
 or (/and) simpler.
 A software licensing from Microsoft won't apply to Linux kernel, so I'm
 assuming that you're referring to some patent that they could be filled
 about RC6 mode 6A.

 I don't know if is there any US patent pending about it (AFAIK, only US
 accepts software patents), but there are some prior-art for IR key
 decoding. So, I don't see what innovation RC6 would be adding. 
 If it is some new way to transmit waves, the patent issues
 aren't related to software, and the device manufacturer had already 
 handled
 it when they made their devices.

 If it is just a new keytable, this issue 
 could be easily solved by loading the keytable via userspace.

 Also, assuming that you can use the driver only with a hardware that comes
 with a licensed software, the user has already the license for using it.

 Do you have any details on what patents they are claiming?
 The US Philips RC-6 patent is US Patent 5,877,702

 http://www.google.com/patents?vid=USPAT5877702

 Click on download PDF to get a copy of the whole patent.

 I am not a lawyer.  Philips claims' all appear to tie to a transmitter
 or receiver as part of a system, but most of the claims are about
 information and bit positions and lengths.
 ...
 IMO, given

 a. the dearth of public information about RC-6, indicating someone
 thinks it's their trade secret or intellectual property

 b. Microsoft claiming to license something related to the MCE remote
 protocols (which are obviously RC-6 Mode 6A),

 c. my inability to draw a clear, bright line that RC-6 Mode 6A
 encoding and decoding, as needed by MCE remotes, implemented in software
 doesn't violate anyone's government granted rights to exclusivity.

 I think it's much better to implement software RC-6 Mode 6A encoding and
 decoding in user space, doing only the minimum needed to get the
 hardware setup and going in the kernel.  

 Encoding/decoding of RC-6 by microcontrollers with firmware doesn't
 worry me. 


 Maybe I'm being too conservative here, but I have a personal interest in
 keeping Linux free and unencumbered even in the US which, I cannot deny,
 has a patent system that is screwed up.
 So I had one of the people who does all the license and patent audits
 for Fedora packages look at the Philips patent on RC-6. He's 100%
 positive that the patent *only* covers hardware, there should be no
 problem whatsoever writing a software decoder for RC-6.
 OK.  Thanks for having some professionals take a look.  (I'm assuming
 that's the only patent.)

 So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
 end of the month.

 I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
 a common set of parameters, so I may be able to set up the decoders to
 handle decoding from two different remote types at once.  The HVR boards
 can ship with either type of remote AFAIK.

 I wonder if I can flip the keytables on the fly or if I have to create
 two different input devices?

 
 Can you distinguish between the 2 remotes (not receivers)? Like I said,
 I think the preferred way is to represent every remote that can be
 distinguished from each other as a separate input device. Applications
 expect to query device capabilities and expect them to stay somewhat
 stable (we do support keymap change but I don't think anyone expectes
 flip-flopping).
 
With RC-5, you have no fields describing the remote. So, all the driver could
do is an educated guess.

From a quick look I did at the RC-6 Mode 6A docs I found, I suspect that
you can distinguish two different remotes when someone press a key there.

However, I don't think it is a good idea to automatically create a new interface
every time a different vendor is detected. Maybe the user simply have a
RC-6 IR to control his TV and doesn't have any intention on using that
device on his computer.

IMO, the better is to have an API to allow creation of multiple interfaces
per IR receiver, based on some scancode matching table and/or on some
matching mask.

It should be possible to use the filter API to match different IR's by
vendor/product on protocols that supports it, or to match address/command
tuples on protocols where you just have those fields.

Cheers,
Mauro.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-08 Thread Andy Walls
On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
 On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:

  So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
  end of the month.
  
  I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
  a common set of parameters, so I may be able to set up the decoders to
  handle decoding from two different remote types at once.  The HVR boards
  can ship with either type of remote AFAIK.
  
  I wonder if I can flip the keytables on the fly or if I have to create
  two different input devices?
  
 
 Can you distinguish between the 2 remotes (not receivers)?

Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
(Honestly I could pile on more protocols that have similar pulse time
periods, but that's complexity for no good reason and I don't know of a
vendor that bundles 3 types of remotes per TV card.)


  Like I said,
 I think the preferred way is to represent every remote that can be
 distinguished from each other as a separate input device.

OK.  With RC-5, NEC, and RC-6 at least there is also an address or
system byte or word to distingish different remotes.  However creating
multiple input devices on the fly for detected remotes would be madness
- especially with a decoding error in the address bits.  

Any one vendor usually picks one address for their bundled remote.
Hauppaugue uses address 0x1e for it's RC-5 remotes AFAICT.



  Applications
 expect to query device capabilities and expect them to stay somewhat
 stable (we do support keymap change but I don't think anyone expectes
 flip-flopping).

OK.

--
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-08 Thread Andy Walls
On Tue, 2009-12-08 at 09:32 -0200, Mauro Carvalho Chehab wrote:
 Andy Walls wrote:
  On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:

  So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
  end of the month.
 
 Good! Please, try to design the decoder as an independent module that gets
 data from a kfifo and generate scancodes for the input API.

Hmmm.  Let me see how the protoype turns out keeping that design
objective in mind.  I've already got the current RC-5 and NEC decoding
state machines in cx23885-input a bit layered, but they are taking
advantage of specific events signaled by my v4l2_subdev implementation.

Strictly speaking the state machines don't have to.  All of the remote
protocols I have played with make framing pretty easy.



  I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
  a common set of parameters, so I may be able to set up the decoders to
  handle decoding from two different remote types at once.  The HVR boards
  can ship with either type of remote AFAIK.
  
  I wonder if I can flip the keytables on the fly or if I have to create
  two different input devices?
 
 IMO, the better is, by default, to open just one input device per IR receiver.
 From what I understand from our discussions, if the user wants to filter IR
 commands into several input interfaces, some userspace interface will be 
 provided to allow the creation of other input interfaces for that purpose.

Hmm. That's not what I just thought I read from Dmitry

Oh well.  If I don'y get it done by 24 Dec, it'll be in the new year.


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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-08 Thread Jon Smirl
On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls awa...@radix.net wrote:
 On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
 On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:

  So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
  end of the month.
 
  I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
  a common set of parameters, so I may be able to set up the decoders to
  handle decoding from two different remote types at once.  The HVR boards
  can ship with either type of remote AFAIK.
 
  I wonder if I can flip the keytables on the fly or if I have to create
  two different input devices?
 

 Can you distinguish between the 2 remotes (not receivers)?

 Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
 (Honestly I could pile on more protocols that have similar pulse time
 periods, but that's complexity for no good reason and I don't know of a
 vendor that bundles 3 types of remotes per TV card.)


  Like I said,
 I think the preferred way is to represent every remote that can be
 distinguished from each other as a separate input device.

 OK.  With RC-5, NEC, and RC-6 at least there is also an address or
 system byte or word to distingish different remotes.  However creating
 multiple input devices on the fly for detected remotes would be madness
 - especially with a decoding error in the address bits.

I agree that creating devices on the fly has problems. Another
solution is to create one device for each map that is loaded. There
would be a couple built-in maps for bundled remotes - each would
create a device. Then the user could load more maps with each map
creating a device.

Incoming scancodes are matched against all of the loaded maps and a
keycode event is generated if a match occurs.

This illustrates why there should an EV_IR event which communicates
scancodes, without this event you can't see the scancodes that don't
match a map entry. A scancode would be first matched against the map,
then if there as no match an EV_IR event would be reported.



 Any one vendor usually picks one address for their bundled remote.
 Hauppaugue uses address 0x1e for it's RC-5 remotes AFAICT.



  Applications
 expect to query device capabilities and expect them to stay somewhat
 stable (we do support keymap change but I don't think anyone expectes
 flip-flopping).

 OK.

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




-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-08 Thread Mauro Carvalho Chehab
Andy Walls wrote:
 On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
 On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
 
 So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
 end of the month.

 I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
 a common set of parameters, so I may be able to set up the decoders to
 handle decoding from two different remote types at once.  The HVR boards
 can ship with either type of remote AFAIK.

 I wonder if I can flip the keytables on the fly or if I have to create
 two different input devices?

 Can you distinguish between the 2 remotes (not receivers)?
 
 Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
 (Honestly I could pile on more protocols that have similar pulse time
 periods, but that's complexity for no good reason and I don't know of a
 vendor that bundles 3 types of remotes per TV card.)

You'll be distinguishing the protocol, not the remote. If I understood
Dmitry's question, he is asking if you can distinguish between two different
remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5
and another RC-6.

  Like I said,
 I think the preferred way is to represent every remote that can be
 distinguished from each other as a separate input device.
 
 OK.  With RC-5, NEC, and RC-6 at least there is also an address or
 system byte or word to distingish different remotes.  However creating
 multiple input devices on the fly for detected remotes would be madness
 - especially with a decoding error in the address bits.  
 
 Any one vendor usually picks one address for their bundled remote.
 Hauppaugue uses address 0x1e for it's RC-5 remotes AFAICT.

The address field on RC-5 protocol is not meant to distinguish different
vendors, but different applications. It identifies that a code should
be sent to a TV or a VCR, or a DVD or a SAT.

In the case of bundled IR's, some vendors like Hauppauge opted to use a
reserved address to avoid conflicts with other equipments. It happens that
vendor's reserved address can be different between two different vendors,
but is just an educated guess to say that an address equal to 0x1e is Hauppauge.

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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-08 Thread Mauro Carvalho Chehab
Jon Smirl wrote:
 On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls awa...@radix.net wrote:
 On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
 On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
 So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
 end of the month.

 I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
 a common set of parameters, so I may be able to set up the decoders to
 handle decoding from two different remote types at once.  The HVR boards
 can ship with either type of remote AFAIK.

 I wonder if I can flip the keytables on the fly or if I have to create
 two different input devices?

 Can you distinguish between the 2 remotes (not receivers)?
 Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
 (Honestly I could pile on more protocols that have similar pulse time
 periods, but that's complexity for no good reason and I don't know of a
 vendor that bundles 3 types of remotes per TV card.)


  Like I said,
 I think the preferred way is to represent every remote that can be
 distinguished from each other as a separate input device.
 OK.  With RC-5, NEC, and RC-6 at least there is also an address or
 system byte or word to distingish different remotes.  However creating
 multiple input devices on the fly for detected remotes would be madness
 - especially with a decoding error in the address bits.
 
 I agree that creating devices on the fly has problems. Another
 solution is to create one device for each map that is loaded. There
 would be a couple built-in maps for bundled remotes - each would
 create a device. Then the user could load more maps with each map
 creating a device.

No, please. We currently have already 89 different keymaps in-kernel. Creating
89 different interfaces per IR receiver is not useful at all.

IMO, the interfaces should be created as the keymaps are associated
to an specific IR receiver.

 Incoming scancodes are matched against all of the loaded maps and a
 keycode event is generated if a match occurs.

s/all of the loaded maps/all of the loaded maps per device/

You may have more than one IR receiver on a given machine.

IMO, we may have a mask filter matching also, associated with each keycode
table, to minimize the keycode seek time. Something like:

if (scancode  scancode_mask)
check_scancode()

 This illustrates why there should an EV_IR event which communicates
 scancodes, without this event you can't see the scancodes that don't
 match a map entry. A scancode would be first matched against the map,
 then if there as no match an EV_IR event would be reported.

There's nothing wrong on receiving a scancode that won't map. This can
simply be an event that you don't want to handle (for example, an IR
code sent to user's TV set).

IMO, the better is to provide this scancode at KERN_DEBUG (if debug is
enabled), and via an observer program.

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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-08 Thread Jon Smirl
On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Andy Walls wrote:
 On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
 On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:

 So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
 end of the month.

 I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
 a common set of parameters, so I may be able to set up the decoders to
 handle decoding from two different remote types at once.  The HVR boards
 can ship with either type of remote AFAIK.

 I wonder if I can flip the keytables on the fly or if I have to create
 two different input devices?

 Can you distinguish between the 2 remotes (not receivers)?

 Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
 (Honestly I could pile on more protocols that have similar pulse time
 periods, but that's complexity for no good reason and I don't know of a
 vendor that bundles 3 types of remotes per TV card.)

 You'll be distinguishing the protocol, not the remote. If I understood
 Dmitry's question, he is asking if you can distinguish between two different
 remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5
 and another RC-6.

RC-5 and RC-6 both contain an address field.  My opinion is that
different addresses represent different devices and in general they
should appear on an input devices per address.

However, I prefer a different scheme for splitting the signals apart.
Load separate maps containing scancodes for each address. When the IR
signals come in they are matched against the maps and a keycode is
generated when a match is found. Now there is no need to distinguish
between the remotes. It doesn't matter which remote generated the
signal.

scancode RC5/12/1 - protocol, address, command tuplet. Map this to
KP_1 on interface 1.
scancode RC5/7/1 - protocol, address, command tuplet. Map this to KP_1
on interface 2.

Using the maps to split the commands out also fixes the problem with
Sony remotes which use multiple protocols to control a single device.
scancode Sony12/12/1 - protocol, address, command tuplet. Map this to
power_on on interface 1.
scancode Sony15/12/1 - protocol, address, command tuplet. Map this to
KP_1 on interface 1.



  Like I said,
 I think the preferred way is to represent every remote that can be
 distinguished from each other as a separate input device.

 OK.  With RC-5, NEC, and RC-6 at least there is also an address or
 system byte or word to distingish different remotes.  However creating
 multiple input devices on the fly for detected remotes would be madness
 - especially with a decoding error in the address bits.

 Any one vendor usually picks one address for their bundled remote.
 Hauppaugue uses address 0x1e for it's RC-5 remotes AFAICT.

 The address field on RC-5 protocol is not meant to distinguish different
 vendors, but different applications. It identifies that a code should
 be sent to a TV or a VCR, or a DVD or a SAT.

 In the case of bundled IR's, some vendors like Hauppauge opted to use a
 reserved address to avoid conflicts with other equipments. It happens that
 vendor's reserved address can be different between two different vendors,
 but is just an educated guess to say that an address equal to 0x1e is 
 Hauppauge.

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




-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-08 Thread Mauro Carvalho Chehab
Jon Smirl wrote:
 On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 Andy Walls wrote:
 On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
 On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
 So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
 end of the month.

 I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
 a common set of parameters, so I may be able to set up the decoders to
 handle decoding from two different remote types at once.  The HVR boards
 can ship with either type of remote AFAIK.

 I wonder if I can flip the keytables on the fly or if I have to create
 two different input devices?

 Can you distinguish between the 2 remotes (not receivers)?
 Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
 (Honestly I could pile on more protocols that have similar pulse time
 periods, but that's complexity for no good reason and I don't know of a
 vendor that bundles 3 types of remotes per TV card.)
 You'll be distinguishing the protocol, not the remote. If I understood
 Dmitry's question, he is asking if you can distinguish between two different
 remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5
 and another RC-6.
 
 RC-5 and RC-6 both contain an address field.  My opinion is that
 different addresses represent different devices and in general they
 should appear on an input devices per address.

The same IR can produce two different addresses. The IR bundled with my 
satellite
STB produces two different codes, depending if you previously pressed TV or 
SAT
key (in fact, I think it can even produce different protocols for TV, as it can
be configured to work with different TV sets).

 However, I prefer a different scheme for splitting the signals apart.
 Load separate maps containing scancodes for each address. When the IR
 signals come in they are matched against the maps and a keycode is
 generated when a match is found. Now there is no need to distinguish
 between the remotes. It doesn't matter which remote generated the
 signal.
 
 scancode RC5/12/1 - protocol, address, command tuplet. Map this to
 KP_1 on interface 1.
 scancode RC5/7/1 - protocol, address, command tuplet. Map this to KP_1
 on interface 2.
 
 Using the maps to split the commands out also fixes the problem with
 Sony remotes which use multiple protocols to control a single device.
 scancode Sony12/12/1 - protocol, address, command tuplet. Map this to
 power_on on interface 1.
 scancode Sony15/12/1 - protocol, address, command tuplet. Map this to
 KP_1 on interface 1.
 

I agree.

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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-08 Thread Jon Smirl
On Tue, Dec 8, 2009 at 8:40 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Jon Smirl wrote:
 On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls awa...@radix.net wrote:
 On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
 On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
 So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
 end of the month.

 I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
 a common set of parameters, so I may be able to set up the decoders to
 handle decoding from two different remote types at once.  The HVR boards
 can ship with either type of remote AFAIK.

 I wonder if I can flip the keytables on the fly or if I have to create
 two different input devices?

 Can you distinguish between the 2 remotes (not receivers)?
 Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
 (Honestly I could pile on more protocols that have similar pulse time
 periods, but that's complexity for no good reason and I don't know of a
 vendor that bundles 3 types of remotes per TV card.)


  Like I said,
 I think the preferred way is to represent every remote that can be
 distinguished from each other as a separate input device.
 OK.  With RC-5, NEC, and RC-6 at least there is also an address or
 system byte or word to distingish different remotes.  However creating
 multiple input devices on the fly for detected remotes would be madness
 - especially with a decoding error in the address bits.

 I agree that creating devices on the fly has problems. Another
 solution is to create one device for each map that is loaded. There
 would be a couple built-in maps for bundled remotes - each would
 create a device. Then the user could load more maps with each map
 creating a device.

 No, please. We currently have already 89 different keymaps in-kernel. Creating
 89 different interfaces per IR receiver is not useful at all.

 IMO, the interfaces should be created as the keymaps are associated
 to an specific IR receiver.

Each IR receiver device driver would have a built-in keymap for the
remote bundled with it. When you load the driver it will poke the
input system and install the map. Any additional keymaps would get
loaded from user space. You would load one keymap per input device.

You might have 89 maps in the kernel with each map being built into
the device driver for those 89 IR receivers. But you'll only own one
or two of those devices so only one or two of the 89 maps will load.
Building the map for the bundled receiver into the device driver is an
important part of achieving just works.

I suspect we'll have a 1,000 maps defined after ten years, most of
these maps will be loaded from user space. But you'll only have two or
three loaded at any one time into your kernel. You need one map per
input device created. These maps are tiny, less than 1KB.

Having all of these maps is the price of allowing everyone to use any
more that they please. If you force the use of universal remotes most
of the maps can be eliminated.




 Incoming scancodes are matched against all of the loaded maps and a
 keycode event is generated if a match occurs.

 s/all of the loaded maps/all of the loaded maps per device/

 You may have more than one IR receiver on a given machine.

 IMO, we may have a mask filter matching also, associated with each keycode
 table, to minimize the keycode seek time. Something like:

        if (scancode  scancode_mask)
                check_scancode()

 This illustrates why there should an EV_IR event which communicates
 scancodes, without this event you can't see the scancodes that don't
 match a map entry. A scancode would be first matched against the map,
 then if there as no match an EV_IR event would be reported.

 There's nothing wrong on receiving a scancode that won't map. This can
 simply be an event that you don't want to handle (for example, an IR
 code sent to user's TV set).

 IMO, the better is to provide this scancode at KERN_DEBUG (if debug is
 enabled), and via an observer program.

 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

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

 With RC-5, you have no fields describing the remote. So, all the driver could
 do is an educated guess.

It can't even do that, e.g. single remotes (even the dumb ones) can send
different code groups (addresses) for different keys.

 IMO, the better is to have an API to allow creation of multiple interfaces
 per IR receiver, based on some scancode matching table and/or on some
 matching mask.

I think setting the keytables for each logical device would do.

I.e. just have a way to create additional logical devices. Each can have
its own keytable. The decoders would send their output to all logical
remotes, trying to match the tables etc.

 It should be possible to use the filter API to match different IR's by
 vendor/product on protocols that supports it,

That would mean unnecessary limiting.

 or to match address/command
 tuples on protocols where you just have those fields.

Precisely.
-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-08 Thread Mauro Carvalho Chehab
Jon Smirl wrote:
 On Tue, Dec 8, 2009 at 8:40 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 Jon Smirl wrote:
 On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls awa...@radix.net wrote:
 On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
 On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
 So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
 end of the month.

 I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
 a common set of parameters, so I may be able to set up the decoders to
 handle decoding from two different remote types at once.  The HVR boards
 can ship with either type of remote AFAIK.

 I wonder if I can flip the keytables on the fly or if I have to create
 two different input devices?

 Can you distinguish between the 2 remotes (not receivers)?
 Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
 (Honestly I could pile on more protocols that have similar pulse time
 periods, but that's complexity for no good reason and I don't know of a
 vendor that bundles 3 types of remotes per TV card.)


  Like I said,
 I think the preferred way is to represent every remote that can be
 distinguished from each other as a separate input device.
 OK.  With RC-5, NEC, and RC-6 at least there is also an address or
 system byte or word to distingish different remotes.  However creating
 multiple input devices on the fly for detected remotes would be madness
 - especially with a decoding error in the address bits.
 I agree that creating devices on the fly has problems. Another
 solution is to create one device for each map that is loaded. There
 would be a couple built-in maps for bundled remotes - each would
 create a device. Then the user could load more maps with each map
 creating a device.
 No, please. We currently have already 89 different keymaps in-kernel. 
 Creating
 89 different interfaces per IR receiver is not useful at all.

 IMO, the interfaces should be created as the keymaps are associated
 to an specific IR receiver.
 
 Each IR receiver device driver would have a built-in keymap for the
 remote bundled with it. When you load the driver it will poke the
 input system and install the map. Any additional keymaps would get
 loaded from user space. You would load one keymap per input device.
 
 You might have 89 maps in the kernel with each map being built into
 the device driver for those 89 IR receivers. But you'll only own one
 or two of those devices so only one or two of the 89 maps will load.
 Building the map for the bundled receiver into the device driver is an
 important part of achieving just works.
 
 I suspect we'll have a 1,000 maps defined after ten years, most of
 these maps will be loaded from user space. But you'll only have two or
 three loaded at any one time into your kernel. You need one map per
 input device created. These maps are tiny, less than 1KB.
 
 Having all of these maps is the price of allowing everyone to use any
 more that they please. If you force the use of universal remotes most
 of the maps can be eliminated.

Makes sense. Yet, I would add an option at Kbuild to create a module or not
with the bundled IR keymaps.

So, it should be possible to have all of them completely on userspace or
having them at kernelspace.

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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-08 Thread Jon Smirl
On Tue, Dec 8, 2009 at 8:59 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Jon Smirl wrote:
 On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 Andy Walls wrote:
 On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
 On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
 So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
 end of the month.

 I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
 a common set of parameters, so I may be able to set up the decoders to
 handle decoding from two different remote types at once.  The HVR boards
 can ship with either type of remote AFAIK.

 I wonder if I can flip the keytables on the fly or if I have to create
 two different input devices?

 Can you distinguish between the 2 remotes (not receivers)?
 Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
 (Honestly I could pile on more protocols that have similar pulse time
 periods, but that's complexity for no good reason and I don't know of a
 vendor that bundles 3 types of remotes per TV card.)
 You'll be distinguishing the protocol, not the remote. If I understood
 Dmitry's question, he is asking if you can distinguish between two different
 remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5
 and another RC-6.

 RC-5 and RC-6 both contain an address field.  My opinion is that
 different addresses represent different devices and in general they
 should appear on an input devices per address.

 The same IR can produce two different addresses. The IR bundled with my 
 satellite
 STB produces two different codes, depending if you previously pressed TV or 
 SAT
 key (in fact, I think it can even produce different protocols for TV, as it 
 can
 be configured to work with different TV sets).

You have a multi-function remote. Multi-function remotes combine
multiple single function remotes into a single device. All universal
remotes I have seen are multi-function. They usually combine three to
five single function remotes.

Yours is a two function remote TV and SAT. When you push TV and
SAT you are changing which single function remote is being emulated.
That's why those keys don't send codes. When writing code you should
think of this remote as being two indpendent virtual remotes, not a
single one.

Note that it is common for multfunction remotes to completely change
IR protocol families when you switch which single function remote you
are emulating. I have my universal set for a Sony TV , JVC DVD player
and a Comcast STB. All three of those use different IR protocols.

By using maps containing the two different addresses for TV and
SAT you can split these commands onto two different evdev devices.

This model is complicated by the fact that some remotes that look like
multi-function remotes aren't really multifunction. The remote bundled
with the MS MCE receiver is one. That remote is a single function
device even though it has function buttons for TV, Music, Pictures,
etc.



 However, I prefer a different scheme for splitting the signals apart.
 Load separate maps containing scancodes for each address. When the IR
 signals come in they are matched against the maps and a keycode is
 generated when a match is found. Now there is no need to distinguish
 between the remotes. It doesn't matter which remote generated the
 signal.

 scancode RC5/12/1 - protocol, address, command tuplet. Map this to
 KP_1 on interface 1.
 scancode RC5/7/1 - protocol, address, command tuplet. Map this to KP_1
 on interface 2.

 Using the maps to split the commands out also fixes the problem with
 Sony remotes which use multiple protocols to control a single device.
 scancode Sony12/12/1 - protocol, address, command tuplet. Map this to
 power_on on interface 1.
 scancode Sony15/12/1 - protocol, address, command tuplet. Map this to
 KP_1 on interface 1.


 I agree.

 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-08 Thread Mauro Carvalho Chehab
Krzysztof Halasa wrote:
 Mauro Carvalho Chehab mche...@redhat.com writes:
 IMO, the better is to have an API to allow creation of multiple interfaces
 per IR receiver, based on some scancode matching table and/or on some
 matching mask.
 
 I think setting the keytables for each logical device would do.

Yes.
 
 I.e. just have a way to create additional logical devices. Each can have
 its own keytable. The decoders would send their output to all logical
 remotes, trying to match the tables etc.
 
 It should be possible to use the filter API to match different IR's by
 vendor/product on protocols that supports it,
 
 That would mean unnecessary limiting.

If the mask is (unsigned)-1, it will not add any limit. This should be the 
default.

The advantage of the mask is that you can speedup the keycode decoding by not 
calling
a seek routine in the cases where it doesn't make sense.

Also, the cost of scancode  scancode_mask is cheap enough, comparing with the 
potential optimization gain of not seeking a data in a table that wouldn't 
match anyway.

Also, the IR core may automatically generate such mask, by doing an and 
operation of all
the scancodes at the table during table initialization/changes. If the mask is 
zero, it
defaults to use a (unsigned) -1 mask.

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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-08 Thread Jon Smirl
On Tue, Dec 8, 2009 at 9:16 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Jon Smirl wrote:
 On Tue, Dec 8, 2009 at 8:40 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 Jon Smirl wrote:
 On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls awa...@radix.net wrote:
 On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
 On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
 So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
 end of the month.

 I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
 a common set of parameters, so I may be able to set up the decoders to
 handle decoding from two different remote types at once.  The HVR boards
 can ship with either type of remote AFAIK.

 I wonder if I can flip the keytables on the fly or if I have to create
 two different input devices?

 Can you distinguish between the 2 remotes (not receivers)?
 Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
 (Honestly I could pile on more protocols that have similar pulse time
 periods, but that's complexity for no good reason and I don't know of a
 vendor that bundles 3 types of remotes per TV card.)


  Like I said,
 I think the preferred way is to represent every remote that can be
 distinguished from each other as a separate input device.
 OK.  With RC-5, NEC, and RC-6 at least there is also an address or
 system byte or word to distingish different remotes.  However creating
 multiple input devices on the fly for detected remotes would be madness
 - especially with a decoding error in the address bits.
 I agree that creating devices on the fly has problems. Another
 solution is to create one device for each map that is loaded. There
 would be a couple built-in maps for bundled remotes - each would
 create a device. Then the user could load more maps with each map
 creating a device.
 No, please. We currently have already 89 different keymaps in-kernel. 
 Creating
 89 different interfaces per IR receiver is not useful at all.

 IMO, the interfaces should be created as the keymaps are associated
 to an specific IR receiver.

 Each IR receiver device driver would have a built-in keymap for the
 remote bundled with it. When you load the driver it will poke the
 input system and install the map. Any additional keymaps would get
 loaded from user space. You would load one keymap per input device.

 You might have 89 maps in the kernel with each map being built into
 the device driver for those 89 IR receivers. But you'll only own one
 or two of those devices so only one or two of the 89 maps will load.
 Building the map for the bundled receiver into the device driver is an
 important part of achieving just works.

 I suspect we'll have a 1,000 maps defined after ten years, most of
 these maps will be loaded from user space. But you'll only have two or
 three loaded at any one time into your kernel. You need one map per
 input device created. These maps are tiny, less than 1KB.

 Having all of these maps is the price of allowing everyone to use any
 more that they please. If you force the use of universal remotes most
 of the maps can be eliminated.

 Makes sense. Yet, I would add an option at Kbuild to create a module or not
 with the bundled IR keymaps.

 So, it should be possible to have all of them completely on userspace or
 having them at kernelspace.

Removing the maps for the bundled remotes from the receiver device
drivers will break just works. The map will be in an __init section
of the IR device driver. When it is fed into the input system a RAM
based structure will be created. If you really want the 1KB memory
back, use sysfs to remove the default map.  An embedded system will
have a bundled remote so it is going to want the map. If you want to
change the default map loading a new map will release the memory from
the previous map.


 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-08 Thread Mauro Carvalho Chehab
Jon Smirl wrote:
 On Tue, Dec 8, 2009 at 8:59 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 Jon Smirl wrote:
 On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 Andy Walls wrote:
 On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
 On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
 So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
 end of the month.

 I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
 a common set of parameters, so I may be able to set up the decoders to
 handle decoding from two different remote types at once.  The HVR boards
 can ship with either type of remote AFAIK.

 I wonder if I can flip the keytables on the fly or if I have to create
 two different input devices?

 Can you distinguish between the 2 remotes (not receivers)?
 Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
 (Honestly I could pile on more protocols that have similar pulse time
 periods, but that's complexity for no good reason and I don't know of a
 vendor that bundles 3 types of remotes per TV card.)
 You'll be distinguishing the protocol, not the remote. If I understood
 Dmitry's question, he is asking if you can distinguish between two 
 different
 remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5
 and another RC-6.
 RC-5 and RC-6 both contain an address field.  My opinion is that
 different addresses represent different devices and in general they
 should appear on an input devices per address.
 The same IR can produce two different addresses. The IR bundled with my 
 satellite
 STB produces two different codes, depending if you previously pressed TV 
 or SAT
 key (in fact, I think it can even produce different protocols for TV, as it 
 can
 be configured to work with different TV sets).
 
 You have a multi-function remote.

Yes.

 That's why those keys don't send codes. When writing code you should
 think of this remote as being two indpendent virtual remotes, not a
 single one.

Not really. I may think on it as a single device and use the two groups
of functions to control two aspects at the same application.

For example, I may map the TV group on kaffeine for DVB reception and the
SAT group for DVD (well, probably, in this case, I'll use an IR with
TV and DVD keys, instead ;) ).

 By using maps containing the two different addresses for TV and
 SAT you can split these commands onto two different evdev devices.

True. I can do it, but I can opt to have both mapped as one evdev device as 
well.
This will basically depend on how I want to mount my environment.
 
 This model is complicated by the fact that some remotes that look like
 multi-function remotes aren't really multifunction. The remote bundled
 with the MS MCE receiver is one. That remote is a single function
 device even though it has function buttons for TV, Music, Pictures,
 etc.

It is very common to have such remotes bundled with multimedia devices.

An unsolved question on my mind is how should we map such IR's? Should we
provide a way for them to emulate a multifunction IR (for example, after 
pressing
TV key, subsequent keystrokes would be directed to the TV evdev device?), or
should we let this up to some userspace app to handle this case?
 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-08 Thread Mauro Carvalho Chehab
Jon Smirl wrote:
 On Tue, Dec 8, 2009 at 9:16 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 Jon Smirl wrote:
 On Tue, Dec 8, 2009 at 8:40 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 Jon Smirl wrote:
 On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls awa...@radix.net wrote:
 On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
 On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
 So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
 end of the month.

 I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
 a common set of parameters, so I may be able to set up the decoders to
 handle decoding from two different remote types at once.  The HVR 
 boards
 can ship with either type of remote AFAIK.

 I wonder if I can flip the keytables on the fly or if I have to create
 two different input devices?

 Can you distinguish between the 2 remotes (not receivers)?
 Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
 (Honestly I could pile on more protocols that have similar pulse time
 periods, but that's complexity for no good reason and I don't know of a
 vendor that bundles 3 types of remotes per TV card.)


  Like I said,
 I think the preferred way is to represent every remote that can be
 distinguished from each other as a separate input device.
 OK.  With RC-5, NEC, and RC-6 at least there is also an address or
 system byte or word to distingish different remotes.  However creating
 multiple input devices on the fly for detected remotes would be madness
 - especially with a decoding error in the address bits.
 I agree that creating devices on the fly has problems. Another
 solution is to create one device for each map that is loaded. There
 would be a couple built-in maps for bundled remotes - each would
 create a device. Then the user could load more maps with each map
 creating a device.
 No, please. We currently have already 89 different keymaps in-kernel. 
 Creating
 89 different interfaces per IR receiver is not useful at all.

 IMO, the interfaces should be created as the keymaps are associated
 to an specific IR receiver.
 Each IR receiver device driver would have a built-in keymap for the
 remote bundled with it. When you load the driver it will poke the
 input system and install the map. Any additional keymaps would get
 loaded from user space. You would load one keymap per input device.

 You might have 89 maps in the kernel with each map being built into
 the device driver for those 89 IR receivers. But you'll only own one
 or two of those devices so only one or two of the 89 maps will load.
 Building the map for the bundled receiver into the device driver is an
 important part of achieving just works.

 I suspect we'll have a 1,000 maps defined after ten years, most of
 these maps will be loaded from user space. But you'll only have two or
 three loaded at any one time into your kernel. You need one map per
 input device created. These maps are tiny, less than 1KB.

 Having all of these maps is the price of allowing everyone to use any
 more that they please. If you force the use of universal remotes most
 of the maps can be eliminated.
 Makes sense. Yet, I would add an option at Kbuild to create a module or not
 with the bundled IR keymaps.

 So, it should be possible to have all of them completely on userspace or
 having them at kernelspace.
 
 Removing the maps for the bundled remotes from the receiver device
 drivers will break just works. 

No. This can be provided by an udev application that will load the keytable
when the device is connected.

Of course before adding it into a module, we'll need to write such app.

This will only affects the need of IR during boot time.

 The map will be in an __init section
 of the IR device driver. When it is fed into the input system a RAM
 based structure will be created. 

We can't use __init, since another device needing the keymap may be hot-plugged.

 If you really want the 1KB memory
 back, use sysfs to remove the default map.  An embedded system will
 have a bundled remote so it is going to want the map. 

Yes, but it needs just one map, not all of them. The maps shouldn't be linked
into the drivers, as the same map is used by several different devices on
different drivers. So, the option is to allow customizing the available keymaps,
if CONFIG_EMBEDDED.

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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-08 Thread Jon Smirl
On Tue, Dec 8, 2009 at 9:34 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Jon Smirl wrote:
 On Tue, Dec 8, 2009 at 8:59 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 Jon Smirl wrote:
 On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 Andy Walls wrote:
 On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
 On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
 So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
 end of the month.

 I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
 a common set of parameters, so I may be able to set up the decoders to
 handle decoding from two different remote types at once.  The HVR 
 boards
 can ship with either type of remote AFAIK.

 I wonder if I can flip the keytables on the fly or if I have to create
 two different input devices?

 Can you distinguish between the 2 remotes (not receivers)?
 Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
 (Honestly I could pile on more protocols that have similar pulse time
 periods, but that's complexity for no good reason and I don't know of a
 vendor that bundles 3 types of remotes per TV card.)
 You'll be distinguishing the protocol, not the remote. If I understood
 Dmitry's question, he is asking if you can distinguish between two 
 different
 remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5
 and another RC-6.
 RC-5 and RC-6 both contain an address field.  My opinion is that
 different addresses represent different devices and in general they
 should appear on an input devices per address.
 The same IR can produce two different addresses. The IR bundled with my 
 satellite
 STB produces two different codes, depending if you previously pressed TV 
 or SAT
 key (in fact, I think it can even produce different protocols for TV, as it 
 can
 be configured to work with different TV sets).

 You have a multi-function remote.

 Yes.

 That's why those keys don't send codes. When writing code you should
 think of this remote as being two indpendent virtual remotes, not a
 single one.

 Not really. I may think on it as a single device and use the two groups
 of functions to control two aspects at the same application.

 For example, I may map the TV group on kaffeine for DVB reception and the
 SAT group for DVD (well, probably, in this case, I'll use an IR with
 TV and DVD keys, instead ;) ).

 By using maps containing the two different addresses for TV and
 SAT you can split these commands onto two different evdev devices.

 True. I can do it, but I can opt to have both mapped as one evdev device as 
 well.
 This will basically depend on how I want to mount my environment.

 This model is complicated by the fact that some remotes that look like
 multi-function remotes aren't really multifunction. The remote bundled
 with the MS MCE receiver is one. That remote is a single function
 device even though it has function buttons for TV, Music, Pictures,
 etc.

 It is very common to have such remotes bundled with multimedia devices.

 An unsolved question on my mind is how should we map such IR's? Should we
 provide a way for them to emulate a multifunction IR (for example, after 
 pressing
 TV key, subsequent keystrokes would be directed to the TV evdev device?), or
 should we let this up to some userspace app to handle this case?

Splitting them into multiple devices requires remembering state and
scripting so it needs to be done in user space. If the user wants to
control a radio app and a home automation app they need to choose.
Keep the bundled remote and do some non-trivial scripting or buy a
universal remote.

Universal remotes make it much easier to achieve just works.

The IR core can contain default universal profiles for various classes
of devices. Say Morotola_DVR and SciAtlanta_DVR. The core would check
if the receiver is cable of receiving these profiles before loading
them. There would be ten of these default universal profiles at most
and you can unload them from RAM if they aren't needed.

Now Myth can have a menu with three remote choices:
 Universal Morotola_DVR
 Universal SciAtlanta_DVR
 Bundled

The Bundled choice came from the map built into the IR receiver's device driver.
The other two choices were loaded by the IR core after ensuring that
the hardware could receive from a universal remote.

The core would also load a couple of default radio profiles
 Univeral SonyDR112_RADIO
 Univeral OnkyoTX8255_RADIO
Same for automation and mouse/keyboard emulation.

Myth looks in sysfs and builds a menu containing DVR devices and all
bundled entries. First app to open the Bundled device gets to keep
it.

These apps could take just works even farther. When they start up
they could listen on all three evdev devices:  Morotola_DVR,
SciAtlanta_DVR,   Bundled. And then if you find Myth responding to
unwanted commands you could disable the unwanted profiles by
deselecting them in the Myth 

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-08 Thread Jon Smirl
On Tue, Dec 8, 2009 at 9:40 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Jon Smirl wrote:
 On Tue, Dec 8, 2009 at 9:16 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 Jon Smirl wrote:
 On Tue, Dec 8, 2009 at 8:40 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 Jon Smirl wrote:
 On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls awa...@radix.net wrote:
 On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
 On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
 So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
 end of the month.

 I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 
 with
 a common set of parameters, so I may be able to set up the decoders to
 handle decoding from two different remote types at once.  The HVR 
 boards
 can ship with either type of remote AFAIK.

 I wonder if I can flip the keytables on the fly or if I have to create
 two different input devices?

 Can you distinguish between the 2 remotes (not receivers)?
 Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
 (Honestly I could pile on more protocols that have similar pulse time
 periods, but that's complexity for no good reason and I don't know of a
 vendor that bundles 3 types of remotes per TV card.)


  Like I said,
 I think the preferred way is to represent every remote that can be
 distinguished from each other as a separate input device.
 OK.  With RC-5, NEC, and RC-6 at least there is also an address or
 system byte or word to distingish different remotes.  However creating
 multiple input devices on the fly for detected remotes would be madness
 - especially with a decoding error in the address bits.
 I agree that creating devices on the fly has problems. Another
 solution is to create one device for each map that is loaded. There
 would be a couple built-in maps for bundled remotes - each would
 create a device. Then the user could load more maps with each map
 creating a device.
 No, please. We currently have already 89 different keymaps in-kernel. 
 Creating
 89 different interfaces per IR receiver is not useful at all.

 IMO, the interfaces should be created as the keymaps are associated
 to an specific IR receiver.
 Each IR receiver device driver would have a built-in keymap for the
 remote bundled with it. When you load the driver it will poke the
 input system and install the map. Any additional keymaps would get
 loaded from user space. You would load one keymap per input device.

 You might have 89 maps in the kernel with each map being built into
 the device driver for those 89 IR receivers. But you'll only own one
 or two of those devices so only one or two of the 89 maps will load.
 Building the map for the bundled receiver into the device driver is an
 important part of achieving just works.

 I suspect we'll have a 1,000 maps defined after ten years, most of
 these maps will be loaded from user space. But you'll only have two or
 three loaded at any one time into your kernel. You need one map per
 input device created. These maps are tiny, less than 1KB.

 Having all of these maps is the price of allowing everyone to use any
 more that they please. If you force the use of universal remotes most
 of the maps can be eliminated.
 Makes sense. Yet, I would add an option at Kbuild to create a module or not
 with the bundled IR keymaps.

 So, it should be possible to have all of them completely on userspace or
 having them at kernelspace.

 Removing the maps for the bundled remotes from the receiver device
 drivers will break just works.

 No. This can be provided by an udev application that will load the keytable
 when the device is connected.

Why do you want to pull the 1KB default mapping table out of the
device driver __init section and more it to a udev script? Now we will
have to maintain a parallel udev script for ever receiver's device
driver.

The purpose of putting this table into __init is to get rid of all
these udev scripts in the default case.


 Of course before adding it into a module, we'll need to write such app.

 This will only affects the need of IR during boot time.

 The map will be in an __init section
 of the IR device driver. When it is fed into the input system a RAM
 based structure will be created.

 We can't use __init, since another device needing the keymap may be 
 hot-plugged.

You can handle that with __devinit


 If you really want the 1KB memory
 back, use sysfs to remove the default map.  An embedded system will
 have a bundled remote so it is going to want the map.

 Yes, but it needs just one map, not all of them. The maps shouldn't be linked
 into the drivers, as the same map is used by several different devices on

Link them or #include them, it doesn't make any difference.

 different drivers. So, the option is to allow customizing the available 
 keymaps,
 if CONFIG_EMBEDDED.

 Cheers,
 Mauro.




-- 
Jon Smirl
jonsm...@gmail.com
--
To unsubscribe from this list: send the line 

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-08 Thread Ferenc Wagner
Mauro Carvalho Chehab mche...@redhat.com writes:

 Jon Smirl wrote:

 This model is complicated by the fact that some remotes that look
 like multi-function remotes aren't really multifunction. The remote
 bundled with the MS MCE receiver is one. That remote is a single
 function device even though it has function buttons for TV, Music,
 Pictures, etc.

 An unsolved question on my mind is how should we map such IR's? Should
 we provide a way for them to emulate a multifunction IR (for example,
 after pressing TV key, subsequent keystrokes would be directed to the
 TV evdev device?), or should we let this up to some userspace app to
 handle this case?

This case feels similar to that of Caps Lock, Num Lock and Scrool Lock,
but I don't know if that scheme could be applied here.
-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-08 Thread Mauro Carvalho Chehab
Jon Smirl wrote:
 On Tue, Dec 8, 2009 at 9:34 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 Jon Smirl wrote:
 On Tue, Dec 8, 2009 at 8:59 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 Jon Smirl wrote:
 On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 Andy Walls wrote:
 On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
 On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
 So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
 end of the month.

 I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 
 with
 a common set of parameters, so I may be able to set up the decoders to
 handle decoding from two different remote types at once.  The HVR 
 boards
 can ship with either type of remote AFAIK.

 I wonder if I can flip the keytables on the fly or if I have to create
 two different input devices?

 Can you distinguish between the 2 remotes (not receivers)?
 Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
 (Honestly I could pile on more protocols that have similar pulse time
 periods, but that's complexity for no good reason and I don't know of a
 vendor that bundles 3 types of remotes per TV card.)
 You'll be distinguishing the protocol, not the remote. If I understood
 Dmitry's question, he is asking if you can distinguish between two 
 different
 remotes that may, for example, be using both RC-5 or both RC-6 or one 
 RC-5
 and another RC-6.
 RC-5 and RC-6 both contain an address field.  My opinion is that
 different addresses represent different devices and in general they
 should appear on an input devices per address.
 The same IR can produce two different addresses. The IR bundled with my 
 satellite
 STB produces two different codes, depending if you previously pressed TV 
 or SAT
 key (in fact, I think it can even produce different protocols for TV, as 
 it can
 be configured to work with different TV sets).
 You have a multi-function remote.
 Yes.

 That's why those keys don't send codes. When writing code you should
 think of this remote as being two indpendent virtual remotes, not a
 single one.
 Not really. I may think on it as a single device and use the two groups
 of functions to control two aspects at the same application.

 For example, I may map the TV group on kaffeine for DVB reception and the
 SAT group for DVD (well, probably, in this case, I'll use an IR with
 TV and DVD keys, instead ;) ).

 By using maps containing the two different addresses for TV and
 SAT you can split these commands onto two different evdev devices.
 True. I can do it, but I can opt to have both mapped as one evdev device as 
 well.
 This will basically depend on how I want to mount my environment.

 This model is complicated by the fact that some remotes that look like
 multi-function remotes aren't really multifunction. The remote bundled
 with the MS MCE receiver is one. That remote is a single function
 device even though it has function buttons for TV, Music, Pictures,
 etc.
 It is very common to have such remotes bundled with multimedia devices.

 An unsolved question on my mind is how should we map such IR's? Should we
 provide a way for them to emulate a multifunction IR (for example, after 
 pressing
 TV key, subsequent keystrokes would be directed to the TV evdev device?), or
 should we let this up to some userspace app to handle this case?
 
 Splitting them into multiple devices requires remembering state and
 scripting so it needs to be done in user space.

It shouldn't be hard to do it in kernelspace, since you'll need to have
one evdev interface associated with the IR anyway, but this will add
some extra complexity at the scancode-keycode conversion, but I'm wandering
if we should do it or not.

Maybe the better is to not do it in kernelspace, to avoid adding there an
extra complexity that can easily be done in userspace.

 If the user wants to
 control a radio app and a home automation app they need to choose.
 Keep the bundled remote and do some non-trivial scripting or buy a
 universal remote.

Ok, but using the shipped IR even without a separate address group for
different applications, and having it controlling radio app and tv app
(not simultaneously) should not be hard, but I LIRC already covers such
usecase, so maybe we don't need to worry about it.

 Universal remotes make it much easier to achieve just works.

True.

 The IR core can contain default universal profiles for various classes
 of devices. Say Morotola_DVR and SciAtlanta_DVR. The core would check
 if the receiver is cable of receiving these profiles before loading
 them. There would be ten of these default universal profiles at most
 and you can unload them from RAM if they aren't needed.
 
 Now Myth can have a menu with three remote choices:
  Universal Morotola_DVR
  Universal SciAtlanta_DVR
  Bundled
 
 The Bundled choice came from the map built into the IR receiver's device 
 driver.
 The other two choices 

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-08 Thread Dmitry Torokhov
On Tue, Dec 08, 2009 at 09:44:29AM -0200, Mauro Carvalho Chehab wrote:
 Dmitry Torokhov wrote:
  On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
  On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
  On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:
 
  On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
  Krzysztof Halasa wrote:
  Andy Walls awa...@radix.net writes:
 
  I would also note that RC-6 Mode 6A, used by most MCE remotes, was
  developed by Philips, but Microsoft has some sort of licensing 
  interest
  in it and it is almost surely encumbered somwhow:
  I don't know about legal problems in some countries but from the
  technical POV handling the protocol in the kernel is more efficient
  or (/and) simpler.
  A software licensing from Microsoft won't apply to Linux kernel, so I'm
  assuming that you're referring to some patent that they could be filled
  about RC6 mode 6A.
 
  I don't know if is there any US patent pending about it (AFAIK, only US
  accepts software patents), but there are some prior-art for IR key
  decoding. So, I don't see what innovation RC6 would be adding. 
  If it is some new way to transmit waves, the patent issues
  aren't related to software, and the device manufacturer had already 
  handled
  it when they made their devices.
 
  If it is just a new keytable, this issue 
  could be easily solved by loading the keytable via userspace.
 
  Also, assuming that you can use the driver only with a hardware that 
  comes
  with a licensed software, the user has already the license for using it.
 
  Do you have any details on what patents they are claiming?
  The US Philips RC-6 patent is US Patent 5,877,702
 
  http://www.google.com/patents?vid=USPAT5877702
 
  Click on download PDF to get a copy of the whole patent.
 
  I am not a lawyer.  Philips claims' all appear to tie to a transmitter
  or receiver as part of a system, but most of the claims are about
  information and bit positions and lengths.
  ...
  IMO, given
 
  a. the dearth of public information about RC-6, indicating someone
  thinks it's their trade secret or intellectual property
 
  b. Microsoft claiming to license something related to the MCE remote
  protocols (which are obviously RC-6 Mode 6A),
 
  c. my inability to draw a clear, bright line that RC-6 Mode 6A
  encoding and decoding, as needed by MCE remotes, implemented in software
  doesn't violate anyone's government granted rights to exclusivity.
 
  I think it's much better to implement software RC-6 Mode 6A encoding and
  decoding in user space, doing only the minimum needed to get the
  hardware setup and going in the kernel.  
 
  Encoding/decoding of RC-6 by microcontrollers with firmware doesn't
  worry me. 
 
 
  Maybe I'm being too conservative here, but I have a personal interest in
  keeping Linux free and unencumbered even in the US which, I cannot deny,
  has a patent system that is screwed up.
  So I had one of the people who does all the license and patent audits
  for Fedora packages look at the Philips patent on RC-6. He's 100%
  positive that the patent *only* covers hardware, there should be no
  problem whatsoever writing a software decoder for RC-6.
  OK.  Thanks for having some professionals take a look.  (I'm assuming
  that's the only patent.)
 
  So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
  end of the month.
 
  I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
  a common set of parameters, so I may be able to set up the decoders to
  handle decoding from two different remote types at once.  The HVR boards
  can ship with either type of remote AFAIK.
 
  I wonder if I can flip the keytables on the fly or if I have to create
  two different input devices?
 
  
  Can you distinguish between the 2 remotes (not receivers)? Like I said,
  I think the preferred way is to represent every remote that can be
  distinguished from each other as a separate input device. Applications
  expect to query device capabilities and expect them to stay somewhat
  stable (we do support keymap change but I don't think anyone expectes
  flip-flopping).
  
 With RC-5, you have no fields describing the remote. So, all the driver could
 do is an educated guess.
 
 From a quick look I did at the RC-6 Mode 6A docs I found, I suspect that
 you can distinguish two different remotes when someone press a key there.
 
 However, I don't think it is a good idea to automatically create a new 
 interface
 every time a different vendor is detected. Maybe the user simply have a
 RC-6 IR to control his TV and doesn't have any intention on using that
 device on his computer.
 
 IMO, the better is to have an API to allow creation of multiple interfaces
 per IR receiver, based on some scancode matching table and/or on some
 matching mask.
 
 It should be possible to use the filter API to match different IR's by
 vendor/product on protocols that supports it, or to match address/command
 tuples 

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-08 Thread Dmitry Torokhov
On Tue, Dec 08, 2009 at 07:52:02AM -0500, Jon Smirl wrote:
 On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls awa...@radix.net wrote:
  On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
  On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
 
   So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
   end of the month.
  
   I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
   a common set of parameters, so I may be able to set up the decoders to
   handle decoding from two different remote types at once.  The HVR boards
   can ship with either type of remote AFAIK.
  
   I wonder if I can flip the keytables on the fly or if I have to create
   two different input devices?
  
 
  Can you distinguish between the 2 remotes (not receivers)?
 
  Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
  (Honestly I could pile on more protocols that have similar pulse time
  periods, but that's complexity for no good reason and I don't know of a
  vendor that bundles 3 types of remotes per TV card.)
 
 
   Like I said,
  I think the preferred way is to represent every remote that can be
  distinguished from each other as a separate input device.
 
  OK.  With RC-5, NEC, and RC-6 at least there is also an address or
  system byte or word to distingish different remotes.  However creating
  multiple input devices on the fly for detected remotes would be madness
  - especially with a decoding error in the address bits.
 
 I agree that creating devices on the fly has problems. Another
 solution is to create one device for each map that is loaded. There
 would be a couple built-in maps for bundled remotes - each would
 create a device. Then the user could load more maps with each map
 creating a device.
 
 Incoming scancodes are matched against all of the loaded maps and a
 keycode event is generated if a match occurs.
 

How many sancodes do we need to reliably recognize the device though? I
am not sure users would want to press 5 random buttons in order to start
using the remote, unless it happens exactly once and then we manage to
store the data somewhere.

 This illustrates why there should an EV_IR event which communicates
 scancodes, without this event you can't see the scancodes that don't
 match a map entry. A scancode would be first matched against the map,
 then if there as no match an EV_IR event would be reported.

Just report MSC_SCAN always. As I said elsewhere we can extend it to be
multi-dword if needed (just need to agree on endianness).

-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-08 Thread Dmitry Torokhov
On Tue, Dec 08, 2009 at 07:46:52AM -0500, Andy Walls wrote:
 On Tue, 2009-12-08 at 09:32 -0200, Mauro Carvalho Chehab wrote:
  Andy Walls wrote:
   On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
 
   So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
   end of the month.
  
  Good! Please, try to design the decoder as an independent module that gets
  data from a kfifo and generate scancodes for the input API.
 
 Hmmm.  Let me see how the protoype turns out keeping that design
 objective in mind.  I've already got the current RC-5 and NEC decoding
 state machines in cx23885-input a bit layered, but they are taking
 advantage of specific events signaled by my v4l2_subdev implementation.
 
 Strictly speaking the state machines don't have to.  All of the remote
 protocols I have played with make framing pretty easy.
 
 
 
   I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
   a common set of parameters, so I may be able to set up the decoders to
   handle decoding from two different remote types at once.  The HVR boards
   can ship with either type of remote AFAIK.
   
   I wonder if I can flip the keytables on the fly or if I have to create
   two different input devices?
  
  IMO, the better is, by default, to open just one input device per IR 
  receiver.
  From what I understand from our discussions, if the user wants to filter IR
  commands into several input interfaces, some userspace interface will be 
  provided to allow the creation of other input interfaces for that purpose.
 
 Hmm. That's not what I just thought I read from Dmitry
 

I am a resonable guy ;) In cases when we can certainly say that there
are 2 separate remotes (and we know characteristics somehow) we need to
create 2 input devices. Otherwise we can't ;)

-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-08 Thread Jon Smirl
On Tue, Dec 8, 2009 at 11:27 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Jon Smirl wrote:
 On Tue, Dec 8, 2009 at 9:34 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 Jon Smirl wrote:
 On Tue, Dec 8, 2009 at 8:59 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 Jon Smirl wrote:
 On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 Andy Walls wrote:
 On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
 On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
 So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before 
 the
 end of the month.

 I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 
 with
 a common set of parameters, so I may be able to set up the decoders 
 to
 handle decoding from two different remote types at once.  The HVR 
 boards
 can ship with either type of remote AFAIK.

 I wonder if I can flip the keytables on the fly or if I have to 
 create
 two different input devices?

 Can you distinguish between the 2 remotes (not receivers)?
 Yes.  RC-6 and RC-5 are different enough to distinguish between the 
 two.
 (Honestly I could pile on more protocols that have similar pulse time
 periods, but that's complexity for no good reason and I don't know of a
 vendor that bundles 3 types of remotes per TV card.)
 You'll be distinguishing the protocol, not the remote. If I understood
 Dmitry's question, he is asking if you can distinguish between two 
 different
 remotes that may, for example, be using both RC-5 or both RC-6 or one 
 RC-5
 and another RC-6.
 RC-5 and RC-6 both contain an address field.  My opinion is that
 different addresses represent different devices and in general they
 should appear on an input devices per address.
 The same IR can produce two different addresses. The IR bundled with my 
 satellite
 STB produces two different codes, depending if you previously pressed 
 TV or SAT
 key (in fact, I think it can even produce different protocols for TV, as 
 it can
 be configured to work with different TV sets).
 You have a multi-function remote.
 Yes.

 That's why those keys don't send codes. When writing code you should
 think of this remote as being two indpendent virtual remotes, not a
 single one.
 Not really. I may think on it as a single device and use the two groups
 of functions to control two aspects at the same application.

 For example, I may map the TV group on kaffeine for DVB reception and the
 SAT group for DVD (well, probably, in this case, I'll use an IR with
 TV and DVD keys, instead ;) ).

 By using maps containing the two different addresses for TV and
 SAT you can split these commands onto two different evdev devices.
 True. I can do it, but I can opt to have both mapped as one evdev device as 
 well.
 This will basically depend on how I want to mount my environment.

 This model is complicated by the fact that some remotes that look like
 multi-function remotes aren't really multifunction. The remote bundled
 with the MS MCE receiver is one. That remote is a single function
 device even though it has function buttons for TV, Music, Pictures,
 etc.
 It is very common to have such remotes bundled with multimedia devices.

 An unsolved question on my mind is how should we map such IR's? Should we
 provide a way for them to emulate a multifunction IR (for example, after 
 pressing
 TV key, subsequent keystrokes would be directed to the TV evdev device?), or
 should we let this up to some userspace app to handle this case?

 Splitting them into multiple devices requires remembering state and
 scripting so it needs to be done in user space.

 It shouldn't be hard to do it in kernelspace, since you'll need to have
 one evdev interface associated with the IR anyway, but this will add
 some extra complexity at the scancode-keycode conversion, but I'm wandering
 if we should do it or not.

 Maybe the better is to not do it in kernelspace, to avoid adding there an
 extra complexity that can easily be done in userspace.

 If the user wants to
 control a radio app and a home automation app they need to choose.
 Keep the bundled remote and do some non-trivial scripting or buy a
 universal remote.

 Ok, but using the shipped IR even without a separate address group for
 different applications, and having it controlling radio app and tv app
 (not simultaneously) should not be hard, but I LIRC already covers such
 usecase, so maybe we don't need to worry about it.

 Universal remotes make it much easier to achieve just works.

 True.

 The IR core can contain default universal profiles for various classes
 of devices. Say Morotola_DVR and SciAtlanta_DVR. The core would check
 if the receiver is cable of receiving these profiles before loading
 them. There would be ten of these default universal profiles at most
 and you can unload them from RAM if they aren't needed.

 Now Myth can have a menu with three remote choices:
  Universal Morotola_DVR
  Universal SciAtlanta_DVR
  Bundled

 The 

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-08 Thread Krzysztof Halasa
Jon Smirl jonsm...@gmail.com writes:

 Why do you want to pull the 1KB default mapping table out of the
 device driver __init section and more it to a udev script? Now we will
 have to maintain a parallel udev script for ever receiver's device
 driver.

Of course no. We will need a single program (script etc.) for all
devices. And we will need a database of the known remotes (scan and key
codes).

 You can handle that with __devinit

__devinit is NOP with hot-plug.

Fortunately we don't need the keymaps in the kernel.
For certain uses we may (and may not) need to have one keymap built-in,
perhaps something similar to the embedded initrd.
-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-08 Thread Mauro Carvalho Chehab
Krzysztof Halasa wrote:
 Jon Smirl jonsm...@gmail.com writes:
 
 Why do you want to pull the 1KB default mapping table out of the
 device driver __init section and more it to a udev script? Now we will
 have to maintain a parallel udev script for ever receiver's device
 driver.
 
 Of course no. We will need a single program (script etc.) for all
 devices. And we will need a database of the known remotes (scan and key
 codes).

The keycode database can be easily extracted from kernel drivers by script.
I have it already at V4L/DVB development tree.

 You can handle that with __devinit
 
 __devinit is NOP with hot-plug.
 
 Fortunately we don't need the keymaps in the kernel.
 For certain uses we may (and may not) need to have one keymap built-in,
 perhaps something similar to the embedded initrd.

I still think the better is to have them in kernel, but compiled only
if selected at Kbuild.

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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-08 Thread Mauro Carvalho Chehab
Dmitry Torokhov wrote:

 I am a resonable guy ;) In cases when we can certainly say that there
 are 2 separate remotes (and we know characteristics somehow) we need to
 create 2 input devices. Otherwise we can't ;)
 
Only on very few specific cases (a few protocols), you can be (almost) sure.
Even on this case, universal remotes can fake another IR.

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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-08 Thread Mauro Carvalho Chehab
Jon Smirl wrote:

 I don't like the idea of automatically loading 3 different keycodes at the
 same time. You may have overlaps between different keycode tables. The
 better is to have some userspace GUI that will allow the user to select
 what keycode table(s) he want to be available, if he decides to not use the
 bundled IR.
 
 Of course there is going to be overlap of the keycodes, but not the
 scancodes. There should be almost 100% overlap.

What prevents users to create overlaps at scancodes? We might add some
protection, but, providing that different keycode tables can be used by
different applications, why do we need to prevent it?

 The three maps are there to support a non-technical user, a
 sophisticated user will disable two of them. This works because the
 non-technical user is only going to use one of the three IR device
 profiles. The other two may be loaded, but the user isn't sending any
 IR signals that match their maps.

I doubt you can map all cases with just three profiles.

 
 Where this breaks down is if they are using SciAtlanta_DVR to control
 MythTV and they also happen to have a physical Motorola DVR in the
 same room. 
 The Linux box is going to pick up the commands meant for
 the Motorola DVR and both boxes will respond.. In that cause they will
 need to figure figure out how to disable the Motorola DVR profile.

I used to have a Set Top Box that has some broken code to decode IR. So,
sometimes, when I used to press a key on my TV IR, the STB were getting
the code, producing a really bad result. That's really bad.

A normal user is able to click on some graphical application and
select his IR model. The app may even have some photos or pictures
representing the most used IR's. This is better than letting him to to
to some forum, asking his friends, etc, trying to figure out why his
PC is doing something wrong when he changes a channel on his TV.

 But is a non-technical person likely to have two DVRs in the same
 room?

Well, I know someone that has an 8 year old children with a setup like this: 
a PC monitor that has an IR, and a PC with a TV board also with IR.
Of course, both the monitor and the PC are at the same room.

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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-07 Thread Jarod Wilson
On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:

 On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
 Krzysztof Halasa wrote:
 Andy Walls awa...@radix.net writes:
 
 I would also note that RC-6 Mode 6A, used by most MCE remotes, was
 developed by Philips, but Microsoft has some sort of licensing interest
 in it and it is almost surely encumbered somwhow:
 
 I don't know about legal problems in some countries but from the
 technical POV handling the protocol in the kernel is more efficient
 or (/and) simpler.
 
 A software licensing from Microsoft won't apply to Linux kernel, so I'm
 assuming that you're referring to some patent that they could be filled
 about RC6 mode 6A.
 
 I don't know if is there any US patent pending about it (AFAIK, only US
 accepts software patents), but there are some prior-art for IR key
 decoding. So, I don't see what innovation RC6 would be adding. 
 If it is some new way to transmit waves, the patent issues
 aren't related to software, and the device manufacturer had already handled
 it when they made their devices.
 
 If it is just a new keytable, this issue 
 could be easily solved by loading the keytable via userspace.
 
 Also, assuming that you can use the driver only with a hardware that comes
 with a licensed software, the user has already the license for using it.
 
 Do you have any details on what patents they are claiming?
 
 The US Philips RC-6 patent is US Patent 5,877,702
 
 http://www.google.com/patents?vid=USPAT5877702
 
 Click on download PDF to get a copy of the whole patent.
 
 I am not a lawyer.  Philips claims' all appear to tie to a transmitter
 or receiver as part of a system, but most of the claims are about
 information and bit positions and lengths.
...
 IMO, given
 
 a. the dearth of public information about RC-6, indicating someone
 thinks it's their trade secret or intellectual property
 
 b. Microsoft claiming to license something related to the MCE remote
 protocols (which are obviously RC-6 Mode 6A),
 
 c. my inability to draw a clear, bright line that RC-6 Mode 6A
 encoding and decoding, as needed by MCE remotes, implemented in software
 doesn't violate anyone's government granted rights to exclusivity.
 
 I think it's much better to implement software RC-6 Mode 6A encoding and
 decoding in user space, doing only the minimum needed to get the
 hardware setup and going in the kernel.  
 
 Encoding/decoding of RC-6 by microcontrollers with firmware doesn't
 worry me. 
 
 
 Maybe I'm being too conservative here, but I have a personal interest in
 keeping Linux free and unencumbered even in the US which, I cannot deny,
 has a patent system that is screwed up.

So I had one of the people who does all the license and patent audits for 
Fedora packages look at the Philips patent on RC-6. He's 100% positive that the 
patent *only* covers hardware, there should be no problem whatsoever writing a 
software decoder for RC-6.

-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-07 Thread Mauro Carvalho Chehab
Jarod Wilson wrote:
 On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:
 
 On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:

 Maybe I'm being too conservative here, but I have a personal interest in
 keeping Linux free and unencumbered even in the US which, I cannot deny,
 has a patent system that is screwed up.
 
 So I had one of the people who does all the license and patent audits for 
 Fedora packages look at the Philips patent on RC-6. He's 100% positive 
 that the patent *only* covers hardware, there should be no problem whatsoever
 writing a software decoder for RC-6.

That's good!

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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-07 Thread Andy Walls
On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
 On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:
 
  On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
  Krzysztof Halasa wrote:
  Andy Walls awa...@radix.net writes:
  
  I would also note that RC-6 Mode 6A, used by most MCE remotes, was
  developed by Philips, but Microsoft has some sort of licensing interest
  in it and it is almost surely encumbered somwhow:
  
  I don't know about legal problems in some countries but from the
  technical POV handling the protocol in the kernel is more efficient
  or (/and) simpler.
  
  A software licensing from Microsoft won't apply to Linux kernel, so I'm
  assuming that you're referring to some patent that they could be filled
  about RC6 mode 6A.
  
  I don't know if is there any US patent pending about it (AFAIK, only US
  accepts software patents), but there are some prior-art for IR key
  decoding. So, I don't see what innovation RC6 would be adding. 
  If it is some new way to transmit waves, the patent issues
  aren't related to software, and the device manufacturer had already handled
  it when they made their devices.
  
  If it is just a new keytable, this issue 
  could be easily solved by loading the keytable via userspace.
  
  Also, assuming that you can use the driver only with a hardware that comes
  with a licensed software, the user has already the license for using it.
  
  Do you have any details on what patents they are claiming?
  
  The US Philips RC-6 patent is US Patent 5,877,702
  
  http://www.google.com/patents?vid=USPAT5877702
  
  Click on download PDF to get a copy of the whole patent.
  
  I am not a lawyer.  Philips claims' all appear to tie to a transmitter
  or receiver as part of a system, but most of the claims are about
  information and bit positions and lengths.
 ...
  IMO, given
  
  a. the dearth of public information about RC-6, indicating someone
  thinks it's their trade secret or intellectual property
  
  b. Microsoft claiming to license something related to the MCE remote
  protocols (which are obviously RC-6 Mode 6A),
  
  c. my inability to draw a clear, bright line that RC-6 Mode 6A
  encoding and decoding, as needed by MCE remotes, implemented in software
  doesn't violate anyone's government granted rights to exclusivity.
  
  I think it's much better to implement software RC-6 Mode 6A encoding and
  decoding in user space, doing only the minimum needed to get the
  hardware setup and going in the kernel.  
  
  Encoding/decoding of RC-6 by microcontrollers with firmware doesn't
  worry me. 
  
  
  Maybe I'm being too conservative here, but I have a personal interest in
  keeping Linux free and unencumbered even in the US which, I cannot deny,
  has a patent system that is screwed up.
 
 So I had one of the people who does all the license and patent audits
 for Fedora packages look at the Philips patent on RC-6. He's 100%
 positive that the patent *only* covers hardware, there should be no
 problem whatsoever writing a software decoder for RC-6.

OK.  Thanks for having some professionals take a look.  (I'm assuming
that's the only patent.)

So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
end of the month.

I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
a common set of parameters, so I may be able to set up the decoders to
handle decoding from two different remote types at once.  The HVR boards
can ship with either type of remote AFAIK.

I wonder if I can flip the keytables on the fly or if I have to create
two different input devices?

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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-07 Thread Dmitry Torokhov
On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
 On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
  On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:
  
   On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
   Krzysztof Halasa wrote:
   Andy Walls awa...@radix.net writes:
   
   I would also note that RC-6 Mode 6A, used by most MCE remotes, was
   developed by Philips, but Microsoft has some sort of licensing interest
   in it and it is almost surely encumbered somwhow:
   
   I don't know about legal problems in some countries but from the
   technical POV handling the protocol in the kernel is more efficient
   or (/and) simpler.
   
   A software licensing from Microsoft won't apply to Linux kernel, so I'm
   assuming that you're referring to some patent that they could be filled
   about RC6 mode 6A.
   
   I don't know if is there any US patent pending about it (AFAIK, only US
   accepts software patents), but there are some prior-art for IR key
   decoding. So, I don't see what innovation RC6 would be adding. 
   If it is some new way to transmit waves, the patent issues
   aren't related to software, and the device manufacturer had already 
   handled
   it when they made their devices.
   
   If it is just a new keytable, this issue 
   could be easily solved by loading the keytable via userspace.
   
   Also, assuming that you can use the driver only with a hardware that 
   comes
   with a licensed software, the user has already the license for using it.
   
   Do you have any details on what patents they are claiming?
   
   The US Philips RC-6 patent is US Patent 5,877,702
   
   http://www.google.com/patents?vid=USPAT5877702
   
   Click on download PDF to get a copy of the whole patent.
   
   I am not a lawyer.  Philips claims' all appear to tie to a transmitter
   or receiver as part of a system, but most of the claims are about
   information and bit positions and lengths.
  ...
   IMO, given
   
   a. the dearth of public information about RC-6, indicating someone
   thinks it's their trade secret or intellectual property
   
   b. Microsoft claiming to license something related to the MCE remote
   protocols (which are obviously RC-6 Mode 6A),
   
   c. my inability to draw a clear, bright line that RC-6 Mode 6A
   encoding and decoding, as needed by MCE remotes, implemented in software
   doesn't violate anyone's government granted rights to exclusivity.
   
   I think it's much better to implement software RC-6 Mode 6A encoding and
   decoding in user space, doing only the minimum needed to get the
   hardware setup and going in the kernel.  
   
   Encoding/decoding of RC-6 by microcontrollers with firmware doesn't
   worry me. 
   
   
   Maybe I'm being too conservative here, but I have a personal interest in
   keeping Linux free and unencumbered even in the US which, I cannot deny,
   has a patent system that is screwed up.
  
  So I had one of the people who does all the license and patent audits
  for Fedora packages look at the Philips patent on RC-6. He's 100%
  positive that the patent *only* covers hardware, there should be no
  problem whatsoever writing a software decoder for RC-6.
 
 OK.  Thanks for having some professionals take a look.  (I'm assuming
 that's the only patent.)
 
 So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
 end of the month.
 
 I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
 a common set of parameters, so I may be able to set up the decoders to
 handle decoding from two different remote types at once.  The HVR boards
 can ship with either type of remote AFAIK.
 
 I wonder if I can flip the keytables on the fly or if I have to create
 two different input devices?
 

Can you distinguish between the 2 remotes (not receivers)? Like I said,
I think the preferred way is to represent every remote that can be
distinguished from each other as a separate input device. Applications
expect to query device capabilities and expect them to stay somewhat
stable (we do support keymap change but I don't think anyone expectes
flip-flopping).

-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-29 Thread Jarod Wilson
On Nov 27, 2009, at 12:06 AM, Jon Smirl wrote:

 On Thu, Nov 26, 2009 at 11:33 PM, Dmitry Torokhov
 dmitry.torok...@gmail.com wrote:
 In the code I posted there is one evdev device for each configured
 remote. Mapped single keycodes are presented on these devices for each
 IR burst. There is no device for the IR receiver.  A LIRC type process
 could watch these devices and then execute scripts based on the
 keycodes reported.
 
 ...
 
 Maybe we should revisit Jon's patchset as well. Regretfully I did not
 have time to do that when it was submitted the last time.
 
 Consider my patch set a technology demo starting point. It shows a
 modern architecture for integrating IR into evdev.  Use the input from
 everyone else to turn these concepts into a real design. I wrote the
 code for the fun of it, I have no commercial interest in IR. I was
 annoyed with how LIRC handled Sony remotes on my home system.
 
 The design is a clean slate implementation of IR for the kernel. No
 attempt was made at legacy compatibility. I was familiar with evdev vs
 /dev/mouse problems from my work on the X server. Because of working
 on X I've also always hated keymaps (that's what drove the configfs
 design).
 
 I wish one of the set top box or TV manufacturers would step up and
 own this.  They are the ones that would benefit the most. Jarod would
 probably be open to some consulting, right?

Mauro may actually have better connections on that front than I do... Thus far, 
I've only talked to a few vendors of IR devices, with mixed results getting any 
sort of support out of them. But its on my todo list to put out some feelers on 
the work front to see if we have any connections that we might be able to 
utilize.

-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-27 Thread Jon Smirl
On Fri, Nov 27, 2009 at 2:33 AM, Christoph Bartelmus l...@bartelmus.de wrote:
 Hi Jon,

 on 27 Nov 09 at 00:06, Jon Smirl wrote:
 [...]
 code for the fun of it, I have no commercial interest in IR. I was
 annoyed with how LIRC handled Sony remotes on my home system.

 Can you elaborate on this?
 I'm not aware of any issue with Sony remotes.

irrecord can't figure out that Sony remotes transmit multiple
protocols so it reverts to raw mode. When trying to figure that out I
started working on the concept of running simultaneous state machines
to decode the pulse timings.  I also had an embedded system with an IR
receiver hooked to a timer input pin.  I started off with a
implementation that ran multiple Sony protocol decoders and used the
input from the timer pin. I know now that I could use irrecord
individually for each group of keys on the Sony remote and then glue
the flies together. But that's the path that caused me to write the
code.

Also throw into pot that I had previously had some very bad
experiences trying to deal with the old mouse and kbd device inside of
the X server. I was aware that evdev was designed to fix all of those
problems. That made me want a fully evdev based design.


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




-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-27 Thread Mauro Carvalho Chehab
Em Thu, 26 Nov 2009 17:06:03 -0200
Mauro Carvalho Chehab mche...@redhat.com escreveu:

 Krzysztof Halasa wrote:
  Mauro Carvalho Chehab mche...@redhat.com writes:
  
  Technically, it is not hard to port this solution to the other
  drivers, but the issue is that we don't have all those IR's to know
  what is the complete scancode that each key produces. So, the hardest
  part is to find a way for doing it without causing regressions, and to
  find a group of people that will help testing the new way.
  
  We don't want to port it to other drivers. We need to have a common
  module which does all RCx decoding. The individual drivers should be as
  simple as possible, something that I outlined in a previous mail.
 
 With the current 7bits mask applied to almost all devices, it is probably not 
 very
 useful for those who want to use generic IRs. We really need to port the 
 solution
 we've done on dvb-usb to the other drivers, allowing them to have the entire
 scancode at the tables while keep supporting table replacement. 
 
 The issue is that we currently have only 7bits of the scan codes produced by 
 the IR's.
 So, we need to re-generate the keycode tables for each IR after the changes 
 got applied.

Ok, I got some time to add support for tables with the full scan codes at the 
V4L drivers.
In order to not break all tables, I've confined the changes to just one device 
(HVR-950,
at the em28xx driver). The patches were already committed at the -hg 
development tree.

In order to support tables with the full scan codes, all that is needed is to 
add the 
RC5 address + RC5 data when calling ir_input_keydown. So, the change is as 
simple as:

-   ir_input_keydown(ir-input, ir-ir,
-poll_result.rc_data[0]);
+   ir_input_keydown(ir-input, ir-ir,
+poll_result.rc_address  8 |
+poll_result.rc_data[0]);
+   else

An example of such patch can be seen at:
http://linuxtv.org/hg/v4l-dvb/rev/9c38704cfd56

There are still some work to do, since, currently, the drivers will use a table 
with a fixed
size. So, you can replace the current values, but it is not possible to add new 
keys.

The fix for it is simple, but we need to think what would be the better way for 
it. There are
two alternatives:
- A table with a fixed size (like 128 or 256 entries - maybe a modprobe 
parameter
could be used to change its size);
- some way to increase/reduce the table size. In this case, we'll 
likely need some
ioctl 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Christoph Bartelmus
Hi Gerd,

on 26 Nov 09 at 00:22, Gerd Hoffmann wrote:
[...]
 To sum it up: I don't think this information will be useful at all for
 lircd or anyone else.
[...]
 I know that lircd does matching instead of decoding, which allows to
 handle unknown encodings.  Thats why I think there will always be cases
 which only lircd will be able to handle (using raw samples).

 That doesn't make attempts to actually decode the IR samples a useless
 exercise though ;)

Well, in my opinion it is kind of useless. I don't see any use case or any  
demand for passing this kind of information to userspace, at least in the  
LIRC context.
If there's no demand, why bother?

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


Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Christoph Bartelmus
Hi,

on 25 Nov 09 at 12:44, Jarod Wilson wrote:
[...]
 Ah, but the approach I'd take to converting to in-kernel decoding[*] would
 be this:
[...]
 [*] assuming, of course, that it was actually agreed upon that in-kernel
 decoding was the right way, the only way, all others will be shot on sight.

I'm happy to see that the discussion is getting along.
But I'm still a bit hesitant about the in-kernel decoding. Maybe it's just  
because I'm not familiar at all with input layer toolset.

1. For sure in-kernel decoding will require some assistance from userspace  
to load the mapping from IR codes to keys. So, if there needs to be a tool  
in userspace that does some kind of autodetection, why not have a tool  
that does some autodetection and autoconfigures lircd for the current  
device. Lots of code duplication in kernel saved. What's the actual  
benefit of in-kernel decoding?

2. What would be the format of the key map? lircd.conf files already exist  
for a lot of remote controls. Will we have a second incompatible format to  
map the keys in-kernel? Where are the tools that create the key maps for  
new remotes?

Maybe someone can shed some light on this.

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


Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Dmitry Torokhov
On Thu, Nov 26, 2009 at 09:01:00AM +0100, Christoph Bartelmus wrote:
 Hi,
 
 on 25 Nov 09 at 12:44, Jarod Wilson wrote:
 [...]
  Ah, but the approach I'd take to converting to in-kernel decoding[*] would
  be this:
 [...]
  [*] assuming, of course, that it was actually agreed upon that in-kernel
  decoding was the right way, the only way, all others will be shot on sight.
 
 I'm happy to see that the discussion is getting along.
 But I'm still a bit hesitant about the in-kernel decoding. Maybe it's just  
 because I'm not familiar at all with input layer toolset.
 
 1. For sure in-kernel decoding will require some assistance from userspace  
 to load the mapping from IR codes to keys. So, if there needs to be a tool  
 in userspace that does some kind of autodetection, why not have a tool  
 that does some autodetection and autoconfigures lircd for the current  
 device. Lots of code duplication in kernel saved. What's the actual  
 benefit of in-kernel decoding?

Why are you mixing configuration and decoding? Configuration I expect
will be done with the help of userspace. Udev is probably the best
place.

 
 2. What would be the format of the key map? lircd.conf files already exist  
 for a lot of remote controls. Will we have a second incompatible format to  
 map the keys in-kernel? Where are the tools that create the key maps for  
 new remotes?
 

Same as the keymaps for the other input devices I'd expect.

 Maybe someone can shed some light on this.
 
 Christoph

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


Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Gerd Hoffmann

On 11/26/09 08:28, Christoph Bartelmus wrote:

Hi Gerd,

on 26 Nov 09 at 00:22, Gerd Hoffmann wrote:
[...]

To sum it up: I don't think this information will be useful at all for
lircd or anyone else.

[...]

I know that lircd does matching instead of decoding, which allows to
handle unknown encodings.  Thats why I think there will always be cases
which only lircd will be able to handle (using raw samples).

That doesn't make attempts to actually decode the IR samples a useless
exercise though ;)


Well, in my opinion it is kind of useless. I don't see any use case or any
demand for passing this kind of information to userspace, at least in the
LIRC context.
If there's no demand, why bother?


There have been complains about this getting lost somewhere in this 
thread, so it looks like there are people which do care.


cheers,
  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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Gerd Hoffmann

On 11/26/09 07:23, Jarod Wilson wrote:

Well, when mythtv was started, I don't know that there were many
input layer remotes around... lirc was definitely around though.


lirc predates the input layer IR drivers by years, maybe even the input 
layer itself.


The main reason for the input layer IR drivers appearing was lirc not 
being mainline.  A in-kernel driver (bttv in that case) which depends on 
a out-of-tree subsystem for IR support was simply a pain in the ass for 
both maintainer (/me back then) and users.


At least for IR hardware which allows access to the raw samples it 
certainly makes sense to support lirc, additional to the current (or 
improved) input layer support.



The lirc support in mythtv actually relies on mapping remote button
names as defined in lircd.conf to keyboard key strokes. As mentioned
elsewhere in this beast of a thread, mythtv doesn't currently support
things like KEY_PLAY, KEY_VOLUMEUP, KEY_CHANNELUP, etc. just yet, but
I intend on fixing that...


lircd can handle the input layer as input as well, so you actually can 
remap things via lircd even for pure input layer drivers.  mythtv 
handling KEY_VOLUMEUP directly would be more elegant though.


cheers,
  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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Krzysztof Halasa wrote:
 Mauro Carvalho Chehab mche...@redhat.com writes:
 
 (This is no recommendation for lirc.  I have no idea whether a
 pulse/space - scancode - keycode translation would be practical
 there.)
 
 It would, but not exactly in the present shape.
 
 For example, there are several bttv and saa7134 devices that polls (or 
 receive
 IRQ interrupts) to detect pulses (and the absense of them) in order to create
 a pulse/space code. The conversion from pulse/space to scancode is done 
 inside
 the driver, with the help of some generic routines and based on the protocol
 specifications.
 
 Right. There are currently several problems (I'm quite familiar with
 saa713x RC5 code): the one that it barely works and is not implemented
 for most such GPIO/IRQ-driven cards (as of 2.6.29 or so). This could
 be fixed, I even have a working though quickdirty patch. Another: the
 RC5 allows for groups and codes within groups. The mapping can only use
 one group, and there can only be one mapping. These design limitations
 mean it's unusable in many cases.

This is a current limitation, since the saa713x code converts the RC5 code into 
a 7bits
scancode, by applying a mask. One of the reasons for that conversion is that 
the two 
ioctls that allows reading/changing the keycode table (EVIOCSKEYCODE and 
EVIOCGKEYCODE)
were implemented via a table with a fixed size of 128 entries.

We already have an implementation at the dvb-usb driver that uses a table 
without
such limits, where the IR scancode is completely stored there. So, you can 
create
any arbitrary scancode -- keycode table there.

Technically, it is not hard to port this solution to the other drivers, but the 
issue
is that we don't have all those IR's to know what is the complete scancode that
each key produces. So, the hardest part is to find a way for doing it without
causing regressions, and to find a group of people that will help testing the 
new way.

Maybe one alternative would be to add a modprobe parameter at the converted 
drivers
to allow them to work with the old behavior, after their migration.

 Those devices where the decoding is done by software can support any
 IR protocols.
 
 Yes, and there can be multiple remote controllers, and multiple code
 groups within a remote.
 
 This can be solved by adding a few ioctls to enumerate the supported
 protocols and to select the one(s) that will be handled by the kernel
 driver.
 
 The driver may have to handle many protocols simultaneously. This is not
 a problem from a technical POV.

There are 3 different situations:
1) hardware where you can support multiple protocols at the same time;
2) hardware that supports one programmable protocol;
3) hardware that support just one (or a limited set) of protocols.

In general, (1) applies only to those devices that outputs a raw pulse/space 
code,
where they just connect the IR sensor to a generic I/O pin and let the software
to decode the code. This is the case of most of cheapest devices. Yet, you can
find some cheap devices with low-cost micro-controllers with a dedicated 
firmware
on its ROM, doing (2).

The most commonly found hardware, in general have a chip to decode IR 
pulse/space
sequences, converting it on a scancode and implementing (3).

That's said, a raw input interface, only fits on case (1). On the other hand, 
the
existing input API works for all types of IR. However, we need to add the ioctls
to allow protocol selection, to better handle (1) and (3).

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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Andy Walls
On Thu, 2009-11-26 at 01:23 -0500, Jarod Wilson wrote:
 On Nov 26, 2009, at 12:49 AM, Dmitry Torokhov wrote:
 
  On Mon, Nov 23, 2009 at 07:53:57PM -0500, Andy Walls wrote:
  On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote:
  Czesc Krzysztof,
  
  on 23 Nov 09 at 15:14, Krzysztof Halasa wrote:
  [...]
  I think we shouldn't at this time worry about IR transmitters.
  
  Sorry, but I have to disagree strongly.
  Any interface without transmitter support would be absolutely 
  unacceptable  
  for many LIRC users, including myself.
  
  I agree with Christoph.  
  
  Is it that the input subsystem is better developed and seen as a
  leverage point for development and thus an easier place to get results
  earlier?  If so, then one should definitely deal with transmitters early
  in the design, as that is where the most unknowns lie.
  
  With the end of analog TV, people will have STBs feeding analog only
  video cards.  Being able to change the channel on the STB with an IR
  transmitter controlled by applications like MythTV is essential.
  
  
  And on some different notes:
  
  I generally don't understand the LIRC aversion I perceive in this thread
  (maybe I just have a skewed perception).  Aside for a video card's
  default remote setup, the suggestions so far don't strike me as any
  simpler for the end user than LIRC -- maybe I'm just used to LIRC.  LIRC
  already works for both transmit and receive and has existing support in
  applications such as MythTV and mplayer.
  
  Is it that LIRC supports MythTV and mplayer or MythTV and mplayer are
  forced to support lirc because the remores are not available through
  other means? I believe it is the latter and applications writers would
  be happy to reduce number of ways they get button data.
 
 Well, when mythtv was started, I don't know that there were many input layer 
 remotes around... lirc was definitely around though. serial receivers and 
 transmitters, both supported by lirc_serial, were the most frequently used 
 devices outside of plain old keyboards. The lirc support in mythtv actually 
 relies on mapping remote button names as defined in lircd.conf to keyboard 
 key strokes. As mentioned elsewhere in this beast of a thread, mythtv doesn't 
 currently support things like KEY_PLAY, KEY_VOLUMEUP, KEY_CHANNELUP, etc. 
 just yet, but I intend on fixing that...
 
  I don't think there is LIRC aversion per se. We are just trying to
  decide whether multiple interfaces for the same data is needed. And
  I don't think that we will completely reject userspace components. Just
  as input subsystem allows for userspace drivers I do not think why we
  can't have the same for the LIRC. But I do think that the primary
  interface for regular userspace consumers (read mplayer and MythTV and
  the likes) should be input event interface (EV_KEY/KEY_*).
 
 Works for me.

Even though two interfaces is a bit of extra work, I'm not averse to
Gerd's suggestions of a dual implementation: input layer for the simple,
common use case, and lirc type interface for more sophisticated usage.

One thing I would like to be provided by the input layer is automatic
key-up after a specified time.  Remote protocols send an initial button
press and then after a certain amount of time (~115 ms for RC-5) send a
repeated code or repeat sequence, if the button is still pressed.
Currently, most of the V4L-DVB drivers have some code to perform a
timeout just to send the key-up event.  That's a good bit of redundant
code for key-up timeouts that I suspect makes sense for the input layer
to handle.

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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Krzysztof Halasa wrote:
 Mauro Carvalho Chehab mche...@redhat.com writes:
 
 If you see patch 3/3, of the lirc submission series, you'll notice a driver
 that has hardware decoding, but, due to lirc interface, the driver generates
 pseudo pulse/space code for it to work via lirc interface.
 
 IOW the driver generates artificial pulse code for lircd?
 I think - pure bloat. lircd can get events from input layer without
 problems. Perhaps I misunderstood?

lircd supports input layer interface. Yet, patch 3/3 exports both devices
that support only pulse/space raw mode and devices that generate scan
codes via the raw mode interface. It does it by generating artificial
pulse codes.
 
 It is very bad to have two interfaces for the same thing, because people
 may do things like that.
 
 I think having a raw scan code interface + the key code cooked mode
 is beneficial. For remotes lacking the raw interface only the latter
 could be used.

It sounds an interesting idea.

 Are you meaning that we should do more than one RC per input event
 interface?
 
 I think so. Why not?
 
 For example, one of my remotes generates codes from at least two RC5
 groups (in only one mode). Currently a remote is limited to only one
 RC5 group.

Yet, both are RC5. This can already be handled by the input layer.
See dvb-usb implementation.

The issue I see is to support at the same time NEC and RC5 protocols. While
this may work with some devices, for others, the hardware won't allow.

 
 I think the mapping should be: key = proto + group + raw code, while
 key2 could be different_proto + different group (if any) + another code.

This may work for protocols up to RC5, that uses either 8 or 16 bits.
However, RC6 mode 6 codes can be 32 bits, and we have only 32 bits
for a scancode. So, we don't have spare bits to represent a protocol, 
if we consider RC6 mode 6 codes as well.

 If so, why do you think we need to handle more than one IR protocol at
 the same time?
 
 Why not?
 There are X-in-1 remotes on the market for years. They can speak many
 protocols at once. One may want to have a protocol to handle DVD apps
 while another for DVB etc.
 And someone may want to use several different remotes, why not?
 Personally I use two different remotes (both set to speak RC5 but what
 if I couldn't set the protocol?). Sure, it requires a bit of hackery
 (not with pulse code and lircd).
 
 I think this will just make the driver more complex without need.
 
 Not much more, and there is a need.

See above. Also, several protocols have a way to check if a keystroke were
properly received. When handling just one protocol, we can use this to double
check the key. However, on a multiprotocol mode, we'll need to disable this
feature.

PS.: For those following those discussions that want to know more about
IR protocols, a good reference is at:
http://www.sbprojects.com/knowledge/ir/ir.htm

Unfortunately, it doesn't describe RC6 mode 6.

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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Andy Walls wrote:

 I generally don't understand the LIRC aversion I perceive in this thread
 (maybe I just have a skewed perception). 

 Regards,
 Andy LIRC Fan-Boy Walls

This is not a lirc love or hate thread. We're simply discussing the better
API's for IR, from the technical standpoint, considering that some users 
may want to use lirc and some users may want to have their IR working 
out-of-the-box.

By not using lirc, users will loose the advantages of having lircd, like 
clicking
on a button and calling automatically the DVD player application, but this means
that their device with the shipped IR will work without needing to do any setup.

Whatever we do, both kind of usages should be possible, since there are demand
for both.

Also, the decision should consider that the existing drivers will need to
support the new way without causing regressions.

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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Andy Walls
On Thu, 2009-11-26 at 10:36 -0200, Mauro Carvalho Chehab wrote:
 Krzysztof Halasa wrote:
  Mauro Carvalho Chehab mche...@redhat.com writes:


 PS.: For those following those discussions that want to know more about
 IR protocols, a good reference is at:
   http://www.sbprojects.com/knowledge/ir/ir.htm
 
 Unfortunately, it doesn't describe RC6 mode 6.

RC-6 Mode 0 and Mode 6A is briefly describe here:

http://www.picbasic.nl/frameload_uk.htm?http://www.picbasic.nl/rc5-rc6_transceiver_uk.htm

That page is slightly wrong, as there is some data coded in the header
such as the RC-6 Mode.

This page is an older version of the sbprojects.com RC-6 page, before
the information on RC-6 Mode 6A was removed:

http://slycontrol.ru/scr/kb/rc6.htm


My personal opinion is that, for non-technical reasons, RC-6 Mode 6A
decoding should not be included in the kernel.  That's why I didn't do
it for the HVR-1850/CX23888.


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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Andy Walls wrote:
 On Mon, 2009-11-23 at 22:46 +0100, Krzysztof Halasa wrote:
 l...@bartelmus.de (Christoph Bartelmus) writes:

 I think we shouldn't at this time worry about IR transmitters.
 Sorry, but I have to disagree strongly.
 Any interface without transmitter support would be absolutely unacceptable
 for many LIRC users, including myself.
 I don't say don't use a transmitter.
 I say the transmitter is not an input device, they are completely
 independent functions. I can't see any reason to try and fit both in the
 same interface - can you?
 
 The underlying hardware need not be completely independent.
 
 For example, the CX2584[0123], CX2388[578], CX23418, and CX2310[012]
 chips have IR hardware that shares a common timing source, interrupt
 line, interrupt status register, etc, between IR Rx and Tx.  They can
 also do things like loopback of Tx to Rx.
 
 That said, an underlying hardware implementation can be split up to user
 space with separate interfaces Tx and Rx.  The underlying driver module
 would have to manage the dependencies.  I would guess that would be
 easier for driver modules, if the userspace interfaces were designed
 with such combined IR Tx/Rx hardware in mind.

True, but, in the case of Rx, there are already API's for it. Tx case is
simpler, as we don't have any API for it yet.

I'm not sure if all the existing hardware for TX currently supports only
raw pulse/code sequencies, but I still think that, even on the Tx case, 
it is better to send scancodes to the driver, and let it do the conversion
to raw pulse/code, if the hardware requires pulse/code instead of scancodes. 

However, as we have green field,
I would add the protocol explicitly for each scancode to be transmitted, like:

struct ir_tx {
enum ir_protocol proto;
u32 scancode;
};

Eventually, we might have a protocol raw and some extra field to allow passing
a raw pulse/code sequence instead of a scancode.

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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Andy Walls
On Thu, 2009-11-26 at 11:25 -0200, Mauro Carvalho Chehab wrote:
 Andy Walls wrote:
  On Mon, 2009-11-23 at 22:46 +0100, Krzysztof Halasa wrote:
  l...@bartelmus.de (Christoph Bartelmus) writes:
 
  I think we shouldn't at this time worry about IR transmitters.
  Sorry, but I have to disagree strongly.
  Any interface without transmitter support would be absolutely unacceptable
  for many LIRC users, including myself.
  I don't say don't use a transmitter.
  I say the transmitter is not an input device, they are completely
  independent functions. I can't see any reason to try and fit both in the
  same interface - can you?
  
  The underlying hardware need not be completely independent.
  
  For example, the CX2584[0123], CX2388[578], CX23418, and CX2310[012]
  chips have IR hardware that shares a common timing source, interrupt
  line, interrupt status register, etc, between IR Rx and Tx.  They can
  also do things like loopback of Tx to Rx.
  
  That said, an underlying hardware implementation can be split up to user
  space with separate interfaces Tx and Rx.  The underlying driver module
  would have to manage the dependencies.  I would guess that would be
  easier for driver modules, if the userspace interfaces were designed
  with such combined IR Tx/Rx hardware in mind.
 
 True, but, in the case of Rx, there are already API's for it. Tx case is
 simpler, as we don't have any API for it yet.
 
 I'm not sure if all the existing hardware for TX currently supports only
 raw pulse/code sequencies, but I still think that, even on the Tx case, 
 it is better to send scancodes to the driver, and let it do the conversion
 to raw pulse/code, if the hardware requires pulse/code instead of scancodes. 

That seems like a decision which will create a lots of duplicative code
in the kernel.  Add it's just busy-work to write such code when a
userspace application in common use already handles the protocols and
sends raw pulses to hardware that expects raw pulses.

 However, as we have green field,
 I would add the protocol explicitly for each scancode to be transmitted, like:
 
 struct ir_tx {
   enum ir_protocol proto;
   u32 scancode;
 };
 
 Eventually, we might have a protocol raw and some extra field to allow 
 passing
 a raw pulse/code sequence instead of a scancode.

I think you would have to.  32 bits is really not enough for all
protocols, and it is already partial encoding of information anyway.

If the Tx driver has to break them down into pulses anyway, why not have
fields with more meaningful names

mode
toggle
customer code (or system code or address),
information (or command)

According to

http://slycontrol.ru/scr/kb/rc6.htm

the information field could be up to 128 bits.

(Not that I'm going to put any RC-6 Mode 6A decoding/encoding in the
kernel.)

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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Jarod Wilson wrote:
 On Nov 23, 2009, at 7:53 PM, Andy Walls wrote:
 
 On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote:
 ...
 I generally don't understand the LIRC aversion I perceive in this thread
 (maybe I just have a skewed perception).  Aside for a video card's
 default remote setup, the suggestions so far don't strike me as any
 simpler for the end user than LIRC -- maybe I'm just used to LIRC.  LIRC
 already works for both transmit and receive and has existing support in
 applications such as MythTV and mplayer.
 
 There's one gripe I agree with, and that is that its still not plug-n-play. 
 Something where udev auto-loads a sane default remote config for say, 
 mceusb transceivers, and the stock mce remote Just Works would be nice, 
 but auto-config is mostly out the window the second you involve transmitters 
 and universal remotes anyway. 

For several devices, an udev rule that auto-loads a sane default keymap does 
work.
Of course, this won't cover 100% of the usages, and I lirc is a very good way
of covering the holes.

 But outside of that, I think objections are largely philosophical -- 
 in a nutshell, the kernel has an input layer, remotes are input devices, 
 and lirc doesn't conform to input layer standards. 

Yes. I think this is mainly the issue. 

The other issue is how to migrate the existing drivers to a new API without 
causing regressions. If we decide that IR's that receive raw pulse/code
should use the raw input interface, this means that a large task force will be
needed to convert the existing drivers to use it.

 I do understand that argument, I just don't currently agree that all IR must
 go through the input layer before the drivers are acceptable for upstream -- 
 especially since lircd can reinject decoded key presses into the input layer 
 via uinput.

IMHO, there are some scenarios for an upcoming kernel IR raw input interface:

1) as a temporary solution for merging lirc drivers, knowing in advance that it 
will
be later converted to the standard input API;

2) as a raw interface for some weird usages, with its usage limited to just a
few device drivers;

3) as the solution for all IR's that produces pulse/code raw sequences;

For (1), while it may make sense, we'll be creating an userspace API that is
meant to be stable, knowing in advance that it will be removed in a close
future.

IMHO, we should avoid (2), since it will be hard to define what is the limited
usage, and I bet that it will evolute to (3) in a long term.

For (3), we need to consider the migration of the existing drivers.

By discarding scenario (2), this means that, in the long term, we'll need to 
either
migrate all existing out-of-tree lirc drivers to the standard input API 
interface 
(scenario 1) or to migrate the existing drivers to the raw input interface 
(scenario 3).

For me, scenario (1) is fine if we add the lirc drivers at drivers/staging.

 I believe Jarod's intent is to have the LIRC components, that need to be
 in kernel modules, moved into kernel mainline to avoid the headaches of
 out of kernel driver maintenance.  I'm not sure it is time well spent
 for developers, or end users, to develop yet another IR receive
 implementation in addition to the ones we suffer with now.
 
 Yeah, a fairly relevant factor in all this is that, despite not being in the 
 linux 
 kernel source tree proper-like, the lirc drivers and lirc have been in use 
 for many
 years by lots of users. The likes of Fedora, Debian, Ubuntu, SUSE, Mandriva, 
 etc. 
 have all been shipping lirc drivers for years now. While lirc certainly isn't 
 perfect (its not always the easiest thing for users to set up), it has 
 actually 
 proven itself pretty robust and useful in the field, once set up. The bulk of 
 breakage in lirc I've personally had to deal with has mostly come in the 
 form of kernel interface changes, which would definitely be mitigated by 
 not having to maintain the drivers out-of-tree any longer.
 
 Now, I'm all for improving things and integrating better with the input 
 subsystem, but what I don't really want to do is break compatibility with the 
 existing setups on thousands (and thousands?) of MythTV boxes around the 
 globe. 
 The lirc userspace can be pretty nimble. If we can come up with a shiny new 
 way 
 that raw IR can be passed out through an input device, I'm pretty sure lirc 
 userspace can be adapted to handle that. If a new input-layer-based transmit 
 interface is developed, we can take advantage of that too. But there's 
 already 
 a very mature lirc interface for doing all of this. So why not start with 
 adding 
 things more or less as they exist right now and evolve the drivers into an 
 idealized form? Getting *something* into the kernel in the first place is a 
 huge step in that direction.

I agree. We should really move forward and add it to kernel as soon as possible,
and start to work on improving the IR support at the upstream kernel.

Jarold,

What do you think of 

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Krzysztof Halasa wrote:
 Andy Walls awa...@radix.net writes:
 
 I would also note that RC-6 Mode 6A, used by most MCE remotes, was
 developed by Philips, but Microsoft has some sort of licensing interest
 in it and it is almost surely encumbered somwhow:
 
 I don't know about legal problems in some countries but from the
 technical POV handling the protocol in the kernel is more efficient
 or (/and) simpler.

A software licensing from Microsoft won't apply to Linux kernel, so I'm
assuming that you're referring to some patent that they could be filled
about RC6 mode 6A.

I don't know if is there any US patent pending about it (AFAIK, only US
accepts software patents), but there are some prior-art for IR key
decoding. So, I don't see what innovation RC6 would be adding. 
If it is some new way to transmit waves, the patent issues
aren't related to software, and the device manufacturer had already handled
it when they made their devices. If it is just a new keytable, this issue 
could be easily solved by loading the keytable via userspace.

Also, assuming that you can use the driver only with a hardware that comes
with a licensed software, the user has already the license for using it.

Do you have any details on what patents they are claiming?

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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Jarod Wilson wrote:
 On Nov 25, 2009, at 12:40 PM, Krzysztof Halasa wrote:
 
 l...@bartelmus.de (Christoph Bartelmus) writes:

 I'm not sure what two ways you are talking about. With the patches posted  
 by Jarod, nothing has to be changed in userspace.
 Everything works, no code needs to be written and tested, everybody is  
 happy.
 The existing drivers use input layer. Do you want part of the tree to
 use existing lirc interface while the other part uses their own
 in-kernel (badly broken for example) code to do precisely the same
 thing?
 
 Took me a minute to figure out exactly what you were talking about. You're 
 referring to the
 current in-kernel decoding done on an ad-hoc basis for assorted remotes 
 bundled with capture devices, correct?

They are not limited to the currently bundled IR's, since almost all drivers 
allow
replacing the existing scancode/keycode table to a new onw.

 Admittedly, unifying those and the lirc driven devices hasn't really been on 
 my radar.

It should be done. Having two ways for doing the same thing is not an option. 
We'll
need to unify them sooner or later. The sooner, the better.

 We can have a good code for both, or we can end up with badly broken
 media drivers and incompatible, suboptimal existing lirc interface
 (though most probably much better in terms of quality, especially after
 Jarod's work).
 
 Well, is there any reason most of those drivers with 
 currently-in-kernel-but-badly-broken decoding can't be converted to
 use the lirc interface if its merged into the kernel?

 And/or, everything
 could converge on a new in-kernel decoding infra that wasn't badly broken.
 Sure, there may be two separate ways of doing essentially the same thing
 for a while, but meh. The lirc way works NOW for an incredibly wide
 variety of receivers, transmitters, IR protocols, etc.

Yes: the same drivers support both pulse/space and in-hardware scancode 
conversion.
In order to use the raw pulse/space API, they'll need to generate pseudo 
pulse/space's.
This would be a dirty solution, IMHO.

Also, changing the drivers would not be that easy, since it will require lots of
tests with IR's and devices that the developers won't have. This is a weaker 
argument,
since no matter what decided, we'll need to change the drivers code (on lirc 
drivers
or on the in-kernel drivers) even without having all hardware available.

 I do concur that Just Works decoding for bundled remotes w/o having to 
 configure anything would be nice, and one way to go about doing that 
 certainly is via in-kernel IR decoding. But at the same time, the second
 you want to use something other than a bundled remote, things fall down, 
 and having to do a bunch of setkeycode ops seems less optimal than simply 
 dropping an appropriate lircd.conf in place.

I don't see this as an issue. We have by far too much work to be done in 
kernelspace
than the changes that are needed on userspace.

Replace the entire scancode table with setkeycode ops is very fast, and needs 
to be
done only once, at lirc startup. Once you load the new IR code at the driver,
the kernel will send the new keycodes to lirc.

It doesn't seem hard to modify lirc to do read the lircd.conf table and replace 
the
IR scancodes at the in-kernel driver. It took me half an hour to write my own 
keycode
loader code, and you can use it as the basis for such feature:
http://linuxtv.org/hg/v4l-dvb/file/tip/v4l2-apps/util/keytable.c


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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Jon Smirl
On Thu, Nov 26, 2009 at 9:45 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Gerd Hoffmann wrote:
 On 11/25/09 19:20, Devin Heitmueller wrote:
 On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilsonja...@wilsonet.com
 wrote:
 Took me a minute to figure out exactly what you were talking
 about. You're referring to the current in-kernel decoding done on
 an ad-hoc basis for assorted remotes bundled with capture devices,
 correct?

 Admittedly, unifying those and the lirc driven devices hasn't
 really been on my radar.

 I think at the end of the day we'll want to have all IR drivers use the
 same interface.  The way the current in-kernel input layer drivers work
 obviously isn't perfect too, so we *must* consider both worlds to get a
 good solution for long-term ...

I made an attempt at implementing all of this a year ago.
http://lkml.org/lkml/2008/11/5/233

All of this kernel code is tiny, about 20K including a driver.

Basic flow works like this:

Add a new IR data type to the input framework
http://lkml.org/lkml/2008/11/5/234

Example mceusb IR input driver
http://lkml.org/lkml/2008/11/5/238

In-kernel decoding of core IR protocols - RC5, RC6, etc
http://lkml.org/lkml/2008/11/5/234

Decoded core protocols pass through a translation map based on configfs
When core protocol matches an entry in configfs it is turned into a
keycode event.
http://lkml.org/lkml/2008/11/5/235

You make a directory in /configfs/remotes for each remote you have.
Making the directory creates a new evdev device.  Under the directory
make an entry for each command generated by the device. These entries
cause the decoded IR data to be mapped into keycodes on the new evdev
device. udev would load these configfs mappings at boot time...

mkdir /config/remotes/sony
 -- this creates a new evdev device
mkdir remotes/sony/one
echo 7 remotes/sony/one/protocol
echo 264 remotes/sony/one/command
echo 2 remotes/sony/one/keycode

This transforms a button push of 1 on my remote into a key stroke for KEY_1

 *   configfs root
 *   --remotes
 *   specific remote
 *   --keymap
 *   protocol
 *   device
 *   command
 *   keycode
 *   --repeat keymaps
 *   
 *   another remote
 *   --more keymaps

You can map the 1 button from multiple remotes to KEY_1 if you want. Or
you can use a single remote to create multiple virtual keyboards.

-

Raw IR pulse data is available in a FIFO via sysfs. You can use this
to figure out new remote protocols.

Two input events are generated
1) an event for the decoded raw IR protocol
2) a keycode event if thedecoded raw IR protocol matches an entry in
the configfs

You can also send pulses.

--

If you want to script this, you would have a user space task that
watches for either the decoded IR codes or the mapped keycodes.

This system also works with user space device drivers. They can inject
input events into the early event flow and they will get processed as
if the event originated in the kernel.

-

Sure you could push the protocol decoding code (RC5, etc) into user
space. Seems like a lot of hassle to move about 3KB of code out of the
kernel.


-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Jon Smirl
BTW, we used to have device specific user space interfaces for mouse
and keyboard. These caused all sort of problems. A lot of work went
into unifying them under evdev.  It will be years until the old,
messed up interfaces can be totally removed.

I'm not in favor of repeating the problems with a device specific user
space interface for IR. I believe all new input devices should
implement the evdev framework.

-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Jarod Wilson wrote:

 I guess the question is what is the interface we want the regular
 userspace (i.e. not lircd) to use. Right now programs has to use 2
 intercfaces - one lirc for dealing with remotes that are not using
 the standard event interface and evdev for remotes using it as well
 as the rest of the input devices.
 
 From the mythtv perspective, using the input layer could yield a better
 out-of-the-box experience -- users don't have to set up an lircrc mapping
 that converts key names as specified in lircd.conf into commands 
 (key strokes, actually) that mythtv understands. For example, a button 
 labeled Play
 in lircd.conf has to be mapped to 'p' in ~/.lircrc for mythtv to do the right 
 thing with it. If everything came through the input layer, be that natively
 or via lircd's uinput reinjection, there would be no need to do that extra 
 mapping step, mythtv would simply handle a KEY_PLAY event. So at worst, 
 one manual mapping to do -- IR signal to standard button name in lircd.conf 
 -- 
 instead of two. But the lircrc approach does also allow more flexibility, 
 in that you can only have a certain app respond to a certain key, if so 
 desired, 
 and remap a key to a different function (KEY_RED, KEY_GREEN, KEY_BLUE, 
 KEY_YELLOW
  -- what should their default functionality be? I know some users map a pair
 of those to mythtv's skip to next commflag point and skip to prior 
 commflag point).
 
 Unfortunately, mythtv currently doesn't handle KEY_PLAY, KEY_VOLUMEUP, etc., 
 etc. at 
 all right now, it operates purely on keys commonly found on a standard 
 keyboard.
 Remedying that is on my TODO list for the next release, if I can carve out 
 the time.

This discussion is a little OT from the API discussions, since it affects both 
out-of-the
box IR reception via input layer and lirc.

All media applications should be capable of handling the corresponding 
KEY_PLAY, KEY_VOLUMEUP ...
keys without needing to do anything else than just handling the corresponding 
keycode.
You shouldn't need to start a daemon or doing anything else for this to work 
out-of-the-box.

They currently don't do it due to historic reasons (it is easier to let 
something else
remap KEY_PLAY into 'p' than to add the proper code there).

When using non-hot-pluggable devices where you're building a dedicated MCE 
hardware (this 
is the common case of MythTV setups), things are not that bad, since, once you 
set your
hardware, it is done.

However, by looking on the number of different new devices, it seems that the 
most common 
type of devices are the TV USB sticks. As they are hot pluggable, eventually 
users may 
have more than one hardware and they expect that the IR layer will work equally 
on
all your devices.

The proper way for supporting it is to have a common application-agnostic 
keycode to indicate
the received events. For example, all IR's should produce 
KEY_CHANNELUP/KEY_CHANNELDOWN events
for changing the channels. Also, on a perfect world, lirc should send this 
event to the
multimedia application that handles TV when such key is pressed, instead of 
converting into
some other keycode. This prevents future problems if, for some reason, the 
application needs to
do something else with that key, or if the key has a different meaning on some 
different contexts.

For example, on some applications, KEY_UP/KEY_DOWN can mean to change a 
channel, but those keys
are also used for menu navigation. However, KEY_CHANNELUP has a clear unique 
meaning: to change a channel. 
The expected behavior, from users perspective, is to mimic a TV box, where if 
you press channel UP
any open menu will be closed and the channel will be changed, but pressing UP 
key will
navigate at the menu. Well, if you map KEY_CHANNELUP as KEY_UP, you'll produce 
a different behavior.

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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Christoph Bartelmus wrote:
 Hi,
 
 on 25 Nov 09 at 12:44, Jarod Wilson wrote:
 [...]
 Ah, but the approach I'd take to converting to in-kernel decoding[*] would
 be this:
 [...]
 [*] assuming, of course, that it was actually agreed upon that in-kernel
 decoding was the right way, the only way, all others will be shot on sight.
 
 I'm happy to see that the discussion is getting along.
 But I'm still a bit hesitant about the in-kernel decoding. Maybe it's just  
 because I'm not familiar at all with input layer toolset.
 
 1. For sure in-kernel decoding will require some assistance from userspace  
 to load the mapping from IR codes to keys.

Current drivers have the IR keycode tables in-kernel also, directly associated
with the board ID.

 So, if there needs to be a tool  
 in userspace that does some kind of autodetection, why not have a tool  
 that does some autodetection and autoconfigures lircd for the current  
 device.

There are userspace tools to change the IR keycode maps. It shouldn't be hard to
change it to autodetect the hardware and to autoconfigure lircd.

 Lots of code duplication in kernel saved. 

Huh? The code is already there.

 What's the actual benefit of in-kernel decoding?

There are two benefits:

1) the developer that adds the hardware also adds the IR code. He has the 
hardware
and the IR for testing, so it means a faster development cycle than waiting for 
someone
else with the same hardware and IR to recode it on some other place. You should
remember that not all developers use lirc;

2) the IR works out of the box.

 2. What would be the format of the key map? lircd.conf files already exist  
 for a lot of remote controls. Will we have a second incompatible format to  
 map the keys in-kernel? Where are the tools that create the key maps for  
 new remotes?

No matter what tool you use, the format should be very close: scancode - 
key_code.

If you wan to take a look on a real example, I'm enclosing the keycode table 
used by
dib0700 driver, as generated/readed by a simple keycode application I made to 
test
the dynamic keycode loading:
http://linuxtv.org/hg/v4l-dvb/file/tip/v4l2-apps/util/keytable.c

Most of the keycodes there are RC5 keys. There are also some NEC keys,
as those devices can work with either RC5 or NEC keycodes, by using a different
parameter during module load.

In the case of this driver, the pulse/space is done in hardware by the DibCom 
chip. The
scancode is sent to PC via the USB interface.

I hope it helps for you to better understand how this works.

Cheers,
Mauro.
0x0700 KEY_MUTE
0x0701 KEY_MENU
0x0739 KEY_POWER
0x0703 KEY_VOLUMEUP
0x0709 KEY_VOLUMEDOWN
0x0706 KEY_CHANNELUP
0x070c KEY_CHANNELDOWN
0x070f KEY_1
0x0715 KEY_2
0x0710 KEY_3
0x0718 KEY_4
0x071b KEY_5
0x071e KEY_6
0x0711 KEY_7
0x0721 KEY_8
0x0712 KEY_9
0x0727 KEY_0
0x0724 KEY_SCREEN
0x072a KEY_TEXT
0x072d KEY_REWIND
0x0730 KEY_PLAY
0x0733 KEY_FASTFORWARD
0x0736 KEY_RECORD
0x073c KEY_STOP
0x073f KEY_CANCEL
0xeb01 KEY_POWER
0xeb02 KEY_1
0xeb03 KEY_2
0xeb04 KEY_3
0xeb05 KEY_4
0xeb06 KEY_5
0xeb07 KEY_6
0xeb08 KEY_7
0xeb09 KEY_8
0xeb0a KEY_9
0xeb0b KEY_VIDEO
0xeb0c KEY_0
0xeb0d KEY_REFRESH
0xeb0f KEY_EPG
0xeb10 KEY_UP
0xeb11 KEY_LEFT
0xeb12 KEY_OK
0xeb13 KEY_RIGHT
0xeb14 KEY_DOWN
0xeb16 KEY_INFO
0xeb17 KEY_RED
0xeb18 KEY_GREEN
0xeb19 KEY_YELLOW
0xeb1a KEY_BLUE
0xeb1b KEY_CHANNELUP
0xeb1c KEY_VOLUMEUP
0xeb1d KEY_MUTE
0xeb1e KEY_VOLUMEDOWN
0xeb1f KEY_CHANNELDOWN
0xeb40 KEY_PAUSE
0xeb41 KEY_HOME
0xeb42 KEY_MENU
0xeb43 KEY_SUBTITLE
0xeb44 KEY_TEXT
0xeb45 KEY_DELETE
0xeb46 KEY_TV
0xeb47 KEY_DVD
0xeb48 KEY_STOP
0xeb49 KEY_VIDEO
0xeb4a KEY_AUDIO
0xeb4b KEY_SCREEN
0xeb4c KEY_PLAY
0xeb4d KEY_BACK
0xeb4e KEY_REWIND
0xeb4f KEY_FASTFORWARD
0xeb54 KEY_PREVIOUS
0xeb58 KEY_RECORD
0xeb5c KEY_NEXT
0x1e00 KEY_0
0x1e01 KEY_1
0x1e02 KEY_2
0x1e03 KEY_3
0x1e04 KEY_4
0x1e05 KEY_5
0x1e06 KEY_6
0x1e07 KEY_7
0x1e08 KEY_8
0x1e09 KEY_9
0x1e0a KEY_KPASTERISK
0x1e0b KEY_RED
0x1e0c KEY_RADIO
0x1e0d KEY_MENU
0x1e0e KEY_GRAVE
0x1e0f KEY_MUTE
0x1e10 KEY_VOLUMEUP
0x1e11 KEY_VOLUMEDOWN
0x1e12 KEY_CHANNEL
0x1e14 KEY_UP
0x1e15 KEY_DOWN
0x1e16 KEY_LEFT
0x1e17 KEY_RIGHT
0x1e18 KEY_VIDEO
0x1e19 KEY_AUDIO
0x1e1a KEY_MEDIA
0x1e1b KEY_EPG
0x1e1c KEY_TV
0x1e1e KEY_NEXT
0x1e1f KEY_BACK
0x1e20 KEY_CHANNELUP
0x1e21 KEY_CHANNELDOWN
0x1e24 KEY_LAST
0x1e25 KEY_OK
0x1e29 KEY_BLUE
0x1e2e KEY_GREEN
0x1e30 KEY_PAUSE
0x1e32 KEY_REWIND
0x1e34 KEY_FASTFORWARD
0x1e35 KEY_PLAY
0x1e36 KEY_STOP
0x1e37 KEY_RECORD
0x1e38 KEY_YELLOW
0x1e3b KEY_GOTO
0x1e3d KEY_POWER
0x0042 KEY_POWER
0x077c KEY_TUNER
0x0f4e KEY_PRINT
0x0840 KEY_SCREEN
0x0f71 KEY_DOT
0x0743 KEY_0
0x0c41 KEY_1
0x0443 KEY_2
0x0b7f KEY_3
0x0e41 KEY_4
0x0643 KEY_5
0x097f KEY_6
0x0d7e KEY_7
0x057c KEY_8
0x0a40 KEY_9
0x0e4e KEY_CLEAR
0x047c KEY_CHANNEL
0x0f41 KEY_LAST
0x0342 KEY_MUTE
0x064c KEY_RESERVED
0x0172 KEY_SHUFFLE
0x0c4e KEY_PLAYPAUSE
0x0b70 KEY_RECORD
0x037d KEY_VOLUMEUP
0x017d KEY_VOLUMEDOWN
0x0242 KEY_CHANNELUP
0x007d KEY_CHANNELDOWN
0x1d00 KEY_0
0x1d01 KEY_1
0x1d02 KEY_2
0x1d03 KEY_3

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Andy Walls wrote:
 On Thu, 2009-11-26 at 11:25 -0200, Mauro Carvalho Chehab wrote:

 I'm not sure if all the existing hardware for TX currently supports only
 raw pulse/code sequencies, but I still think that, even on the Tx case, 
 it is better to send scancodes to the driver, and let it do the conversion
 to raw pulse/code, if the hardware requires pulse/code instead of scancodes. 
 
 That seems like a decision which will create a lots of duplicative code
 in the kernel.  Add it's just busy-work to write such code when a
 userspace application in common use already handles the protocols and
 sends raw pulses to hardware that expects raw pulses.

I don't see how this would create lots of duplicative code.

 However, as we have green field,
 I would add the protocol explicitly for each scancode to be transmitted, 
 like:

 struct ir_tx {
  enum ir_protocol proto;
  u32 scancode;
 };

 Eventually, we might have a protocol raw and some extra field to allow 
 passing
 a raw pulse/code sequence instead of a scancode.
 
 I think you would have to.  32 bits is really not enough for all
 protocols, and it is already partial encoding of information anyway.
 
 If the Tx driver has to break them down into pulses anyway, 

Do all Tx drivers need handle pulse by pulse, or there are some that works
only with scancodes?

 why not have fields with more meaningful names
 
   mode
   toggle
   customer code (or system code or address),
   information (or command)
 
 According to
 
   http://slycontrol.ru/scr/kb/rc6.htm
 
 the information field could be up to 128 bits.

Seems fine to me.

 (Not that I'm going to put any RC-6 Mode 6A decoding/encoding in the
 kernel.)  
 
 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Krzysztof Halasa
Gerd Hoffmann kra...@redhat.com writes:

 Why not?  With RC5 remotes applications can get the device address
 bits for example, which right now are simply get lost in the ir code
 - 
 keycode conversion step.

Right, this in fact makes the input layer interface unusable for many
remotes at this time.
I think the address (aka group) should be just a part of the key
(command) code, IIRC this is what lirc RC5 does (I'm presently using
a custom media version of RC5).

 I know that lircd does matching instead of decoding, which allows to
 handle unknown encodings.  Thats why I think there will always be
 cases which only lircd will be able to handle (using raw samples).

 That doesn't make attempts to actually decode the IR samples a useless
 exercise though ;)

Sure. Especially RC5-like protos are simple to decode, and it's very
reliable, even with a very unstable remote clock source (such as
RC-based = resistor + capacitor).
-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Jarod Wilson

On 11/26/2009 04:14 AM, Gerd Hoffmann wrote:

On 11/26/09 07:23, Jarod Wilson wrote:

Well, when mythtv was started, I don't know that there were many
input layer remotes around... lirc was definitely around though.


lirc predates the input layer IR drivers by years, maybe even the input
layer itself.


That was my guess, but I didn't have a timeline in front of me. :)


The main reason for the input layer IR drivers appearing was lirc not
being mainline. A in-kernel driver (bttv in that case) which depends on
a out-of-tree subsystem for IR support was simply a pain in the ass for
both maintainer (/me back then) and users.

At least for IR hardware which allows access to the raw samples it
certainly makes sense to support lirc, additional to the current (or
improved) input layer support.


I'm liking the idea of a hybrid approach, where IR devices can support 
both lirc and input device interfaces. I think its the most 
regression-proof for end-users, if done correctly, which is one of my 
biggest concerns.



The lirc support in mythtv actually relies on mapping remote button
names as defined in lircd.conf to keyboard key strokes. As mentioned
elsewhere in this beast of a thread, mythtv doesn't currently support
things like KEY_PLAY, KEY_VOLUMEUP, KEY_CHANNELUP, etc. just yet, but
I intend on fixing that...


lircd can handle the input layer as input as well, so you actually can
remap things via lircd even for pure input layer drivers. mythtv
handling KEY_VOLUMEUP directly would be more elegant though.


Yeah, no, I know lircd can attach to an input device. But even if you do 
that, you have to have a mapping that converts KEY_VOLUMEUP as captured 
by lircd into (iirc) right-bracket (]) for mythtv to actually consume 
it. Directly handling definitely needs to be added to mythtv.


--
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Jarod Wilson

On 11/26/2009 08:54 AM, Mauro Carvalho Chehab wrote:

Jarod Wilson wrote:

On Nov 23, 2009, at 7:53 PM, Andy Walls wrote:


On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote:

...

I generally don't understand the LIRC aversion I perceive in this thread
(maybe I just have a skewed perception).  Aside for a video card's
default remote setup, the suggestions so far don't strike me as any
simpler for the end user than LIRC -- maybe I'm just used to LIRC.  LIRC
already works for both transmit and receive and has existing support in
applications such as MythTV and mplayer.


There's one gripe I agree with, and that is that its still not plug-n-play.
Something where udev auto-loads a sane default remote config for say,
mceusb transceivers, and the stock mce remote Just Works would be nice,
but auto-config is mostly out the window the second you involve transmitters
and universal remotes anyway.


For several devices, an udev rule that auto-loads a sane default keymap does 
work.
Of course, this won't cover 100% of the usages, and I lirc is a very good way
of covering the holes.


But outside of that, I think objections are largely philosophical --
in a nutshell, the kernel has an input layer, remotes are input devices,
and lirc doesn't conform to input layer standards.


Yes. I think this is mainly the issue.

The other issue is how to migrate the existing drivers to a new API without
causing regressions. If we decide that IR's that receive raw pulse/code
should use the raw input interface, this means that a large task force will be
needed to convert the existing drivers to use it.


Aversion to regression is definitely a major concern. And why I'm liking 
the idea of a hybrid approach, at least initially.



What do you think of adding lirc at staging while we discuss/improve the API's 
and lircd
support for the input event interface? Do you think this would work?


Sure, I don't see why not. And I've got another dozen or so drivers to 
follow those first three... :)


--
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Krzysztof Halasa
Dmitry Torokhov dmitry.torok...@gmail.com writes:

 In what way the key interface is unsufficient for delivering button
 events?

At present: 128 different keys only (RC5: one group). One remote per
device only.

The protocol itself doesn't have the above limitations, but has others,
with are acceptable for key input.
-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Jarod Wilson wrote:
 On 11/26/2009 08:54 AM, Mauro Carvalho Chehab wrote:
 Jarod Wilson wrote:
 On Nov 23, 2009, at 7:53 PM, Andy Walls wrote:

 On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote:
 ...
 I generally don't understand the LIRC aversion I perceive in this
 thread
 (maybe I just have a skewed perception).  Aside for a video card's
 default remote setup, the suggestions so far don't strike me as any
 simpler for the end user than LIRC -- maybe I'm just used to LIRC. 
 LIRC
 already works for both transmit and receive and has existing support in
 applications such as MythTV and mplayer.

 There's one gripe I agree with, and that is that its still not
 plug-n-play.
 Something where udev auto-loads a sane default remote config for say,
 mceusb transceivers, and the stock mce remote Just Works would be nice,
 but auto-config is mostly out the window the second you involve
 transmitters
 and universal remotes anyway.

 For several devices, an udev rule that auto-loads a sane default
 keymap does work.
 Of course, this won't cover 100% of the usages, and I lirc is a very
 good way
 of covering the holes.

 But outside of that, I think objections are largely philosophical --
 in a nutshell, the kernel has an input layer, remotes are input devices,
 and lirc doesn't conform to input layer standards.

 Yes. I think this is mainly the issue.

 The other issue is how to migrate the existing drivers to a new API
 without
 causing regressions. If we decide that IR's that receive raw pulse/code
 should use the raw input interface, this means that a large task force
 will be
 needed to convert the existing drivers to use it.
 
 Aversion to regression is definitely a major concern. And why I'm liking
 the idea of a hybrid approach, at least initially.

Yes. This indeed seems to be a very good idea.
 
 What do you think of adding lirc at staging while we discuss/improve
 the API's and lircd
 support for the input event interface? Do you think this would work?
 
 Sure, I don't see why not. And I've got another dozen or so drivers to
 follow those first three... :)

Ok. As you said you'll do some work at the patches, could you please send us v3
in order to add it into drivers/staging? 

In the case of the API header file, I would tag at the header file that the API
is experimental, so can be changed without prior announcements, etc (in order to
avoid people to use and rely on it it outside lirc). IMO, the better is to keep
such announcement there while we're still working at the hybrid approach, as we
may need to change something during the development phase.

Dmitry,

While lirc is basically a series of input drivers, considering that they have 
lots
in common with the input drivers at V4L/DVB and that we'll need to work on
some glue to merge both, do you mind if I add the lirc drivers at 
drivers/staging from
my trees? 

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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Krzysztof Halasa wrote:
 Dmitry Torokhov dmitry.torok...@gmail.com writes:
 
 In what way the key interface is unsufficient for delivering button
 events?
 
 At present: 128 different keys only (RC5: one group). One remote per
 device only.
 
 The protocol itself doesn't have the above limitations, but has others,
 with are acceptable for key input.

This is not a limit at the input subsystem. It were a design decision for
some drivers at the V4L subsystem that we need to change.

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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Krzysztof Halasa
Mauro Carvalho Chehab mche...@redhat.com writes:

 1) the developer that adds the hardware also adds the IR code. He has
 the hardware and the IR for testing, so it means a faster development
 cycle than waiting for someone else with the same hardware and IR to
 recode it on some other place. You should remember that not all
 developers use lirc;

It's fine, but please - no keymaps in the kernel (except for fixed
receivers, i.e. the ones which can only work with their own dedicated
remote, and which don't pass RC5/etc. code).

The existing keymaps (those which can be used with lirc) have to be
moved to userspace as well.
-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Krzysztof Halasa
Mauro Carvalho Chehab mche...@redhat.com writes:

 Technically, it is not hard to port this solution to the other
 drivers, but the issue is that we don't have all those IR's to know
 what is the complete scancode that each key produces. So, the hardest
 part is to find a way for doing it without causing regressions, and to
 find a group of people that will help testing the new way.

We don't want to port it to other drivers. We need to have a common
module which does all RCx decoding. The individual drivers should be as
simple as possible, something that I outlined in a previous mail.
-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Krzysztof Halasa wrote:
 Mauro Carvalho Chehab mche...@redhat.com writes:
 
 1) the developer that adds the hardware also adds the IR code. He has
 the hardware and the IR for testing, so it means a faster development
 cycle than waiting for someone else with the same hardware and IR to
 recode it on some other place. You should remember that not all
 developers use lirc;
 
 It's fine, but please - no keymaps in the kernel (except for fixed
 receivers, i.e. the ones which can only work with their own dedicated
 remote, and which don't pass RC5/etc. code).
 
 The existing keymaps (those which can be used with lirc) have to be
 moved to userspace as well.

The removal of the existing keymaps from kernel depends on having an application
to be called from udev to load the proper keymaps when a device is probed.

After having it for a while, we should deprecate the in-kernel keymaps
and move them to userspace.

I also think that it is important to remove the 7 bits limitation from all 
drivers
and re-generate the keymaps, since they'll change after 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Krzysztof Halasa wrote:
 Mauro Carvalho Chehab mche...@redhat.com writes:
 
 Technically, it is not hard to port this solution to the other
 drivers, but the issue is that we don't have all those IR's to know
 what is the complete scancode that each key produces. So, the hardest
 part is to find a way for doing it without causing regressions, and to
 find a group of people that will help testing the new way.
 
 We don't want to port it to other drivers. We need to have a common
 module which does all RCx decoding. The individual drivers should be as
 simple as possible, something that I outlined in a previous mail.

With the current 7bits mask applied to almost all devices, it is probably not 
very
useful for those who want to use generic IRs. We really need to port the 
solution
we've done on dvb-usb to the other drivers, allowing them to have the entire
scancode at the tables while keep supporting table replacement. 

The issue is that we currently have only 7bits of the scan codes produced by 
the IR's.
So, we need to re-generate the keycode tables for each IR after the changes got 
applied.

With respect to a common module, unfortunately most of the work should be done 
on
each driver, since the code that communicates with the hardware is specific to 
each
device. There is a common code (at ir-common.ko) with helper decoding routines.

Please feel free to send us contributions to improve the current code.

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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Krzysztof Halasa wrote:
 Mauro Carvalho Chehab mche...@redhat.com writes:
 
 The issue I see is to support at the same time NEC and RC5 protocols. While
 this may work with some devices, for others, the hardware won't allow.
 
 Sure. We can handle it for the simple devices at least.
 
 I think the mapping should be: key = proto + group + raw code, while
 key2 could be different_proto + different group (if any) + another code.
 This may work for protocols up to RC5, that uses either 8 or 16 bits.
 However, RC6 mode 6 codes can be 32 bits, and we have only 32 bits
 for a scancode. So, we don't have spare bits to represent a protocol, 
 if we consider RC6 mode 6 codes as well.
 
 I don't see this limitation. The number of bits should depend on the
 protocol.

see include/linux/input.h:

struct input_event {
struct timeval time;
__u16 type;
__u16 code;
__s32 value;
};

extending the value to more than 32 bits require some changes at the input 
layer,
probably breaking kernel API.

 
 See above. Also, several protocols have a way to check if a keystroke were
 properly received. When handling just one protocol, we can use this to double
 check the key. However, on a multiprotocol mode, we'll need to disable this
 feature.
 
 I don't think so. We can pass the space/mark data to all (configured,
 i.e. with active mapping) protocol handlers at once. Should a check
 fail, we ignore the data. Perhaps another protocol will make some sense
 out of it.

What happens if it succeeds on two protocol handlers?

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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Andy Walls
On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
 Krzysztof Halasa wrote:
  Andy Walls awa...@radix.net writes:
  
  I would also note that RC-6 Mode 6A, used by most MCE remotes, was
  developed by Philips, but Microsoft has some sort of licensing interest
  in it and it is almost surely encumbered somwhow:
  
  I don't know about legal problems in some countries but from the
  technical POV handling the protocol in the kernel is more efficient
  or (/and) simpler.
 
 A software licensing from Microsoft won't apply to Linux kernel, so I'm
 assuming that you're referring to some patent that they could be filled
 about RC6 mode 6A.
 
 I don't know if is there any US patent pending about it (AFAIK, only US
 accepts software patents), but there are some prior-art for IR key
 decoding. So, I don't see what innovation RC6 would be adding. 
 If it is some new way to transmit waves, the patent issues
 aren't related to software, and the device manufacturer had already handled
 it when they made their devices.

  If it is just a new keytable, this issue 
 could be easily solved by loading the keytable via userspace.
 
 Also, assuming that you can use the driver only with a hardware that comes
 with a licensed software, the user has already the license for using it.
 
 Do you have any details on what patents they are claiming?

The US Philips RC-6 patent is US Patent 5,877,702

http://www.google.com/patents?vid=USPAT5877702

Click on download PDF to get a copy of the whole patent.

I am not a lawyer.  Philips claims' all appear to tie to a transmitter
or receiver as part of a system, but most of the claims are about
information and bit positions and lengths.


I don't know for sure what Microsoft claims to be licensing.  I think it
is the protocol itself:

http://www.microsoft.com/presspass/Press/2002/Apr02/04-16FreestylePhilipsPR.mspx

Under the terms of the agreement, Microsoft and Philips will license to
OEMs an IR protocol based on Philips proprietary RC6 IR technology. The
patented and globally adopted solution minimizes interference from other
remote-control devices in the household. Use of this established
protocol will help ensure uniform development of Windows infrared
remote-control products, which include infrared remote-control units and
remote-control receivers...

http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWEN05007_WinHEC05.ppt

See Slide 5, which has the bullet: How to License RC6

Since the content of the information field in RC-6 Mode 6A is left up to
OEMs, I would not be surprised by bogus innovations in OEM patents
about RC-6 Mode 6A contents.  I would not be at all surprised by
something like a bit to indicate a toggled remote key press in the
information field since RC-6's T bits for mode 6 indicate Mode 6A or
Mode 6B and not toggles.


IMO, given

a. the dearth of public information about RC-6, indicating someone
thinks it's their trade secret or intellectual property

b. Microsoft claiming to license something related to the MCE remote
protocols (which are obviously RC-6 Mode 6A),

c. my inability to draw a clear, bright line that RC-6 Mode 6A
encoding and decoding, as needed by MCE remotes, implemented in software
doesn't violate anyone's government granted rights to exclusivity.

I think it's much better to implement software RC-6 Mode 6A encoding and
decoding in user space, doing only the minimum needed to get the
hardware setup and going in the kernel.  

Encoding/decoding of RC-6 by microcontrollers with firmware doesn't
worry me. 


Maybe I'm being too conservative here, but I have a personal interest in
keeping Linux free and unencumbered even in the US which, I cannot deny,
has a patent system that is screwed up.

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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Christoph Bartelmus
Hi Mauro,

on 26 Nov 09 at 10:36, Mauro Carvalho Chehab wrote:
[...]
 lircd supports input layer interface. Yet, patch 3/3 exports both devices
 that support only pulse/space raw mode and devices that generate scan
 codes via the raw mode interface. It does it by generating artificial
 pulse codes.

Nonsense! There's no generation of artificial pulse codes in the drivers.
The LIRC interface includes ways to pass decoded IR codes of arbitrary  
length to userspace.

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


Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Christoph Bartelmus wrote:
 Hi Mauro,
 
 on 26 Nov 09 at 10:36, Mauro Carvalho Chehab wrote:
 [...]
 lircd supports input layer interface. Yet, patch 3/3 exports both devices
 that support only pulse/space raw mode and devices that generate scan
 codes via the raw mode interface. It does it by generating artificial
 pulse codes.
 
 Nonsense! There's no generation of artificial pulse codes in the drivers.
 The LIRC interface includes ways to pass decoded IR codes of arbitrary  
 length to userspace.

I might have got wrong then a comment in the middle of the 
imon_incoming_packet() of the SoundGraph iMON IR patch:

+   /*
+* Translate received data to pulse and space lengths.
+* Received data is active low, i.e. pulses are 0 and
+* spaces are 1.
+*
+* My original algorithm was essentially similar to
+* Changwoo Ryu's with the exception that he switched
+* the incoming bits to active high and also fed an
+* initial space to LIRC at the start of a new sequence
+* if the previous bit was a pulse.
+*
+* I've decided to adopt his algorithm.
+*/

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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Dmitry Torokhov

On Nov 26, 2009, at 9:46 AM, Krzysztof Halasa k...@pm.waw.pl wrote:


Dmitry Torokhov dmitry.torok...@gmail.com writes:


In what way the key interface is unsufficient for delivering button
events?


At present: 128 different keys only (RC5: one group).


Where did this limitation come from? We have more than 256 keycodes  
already _defined_ in the input core and we can add more if needed.




One remote per
device only.


Why would you want more? One physical device usually corresponds to a  
logical device. If you have 2 remotes create 2 devices.


The protocol itself doesn't have the above limitations, but has  
others,

with are acceptable for key input.
--
Krzysztof Halasa


--
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Christoph Bartelmus
Hi Mauro,

on 26 Nov 09 at 18:59, Mauro Carvalho Chehab wrote:
 Christoph Bartelmus wrote:
[...]
 lircd supports input layer interface. Yet, patch 3/3 exports both devices
 that support only pulse/space raw mode and devices that generate scan
 codes via the raw mode interface. It does it by generating artificial
 pulse codes.

 Nonsense! There's no generation of artificial pulse codes in the drivers.
 The LIRC interface includes ways to pass decoded IR codes of arbitrary
 length to userspace.

 I might have got wrong then a comment in the middle of the
 imon_incoming_packet() of the SoundGraph iMON IR patch:

Indeed, you got it wrong.
As I already explained before, this device samples the signal at a  
constant rate and delivers the current level in a bit-array. This data is  
then condensed to pulse/space data.

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


Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Trent Piepho
On Thu, 26 Nov 2009, Mauro Carvalho Chehab wrote:
  See above. Also, several protocols have a way to check if a keystroke were
  properly received. When handling just one protocol, we can use this to 
  double
  check the key. However, on a multiprotocol mode, we'll need to disable this
  feature.
 
  I don't think so. We can pass the space/mark data to all (configured,
  i.e. with active mapping) protocol handlers at once. Should a check
  fail, we ignore the data. Perhaps another protocol will make some sense
  out of it.

 What happens if it succeeds on two protocol handlers?

Then you use the protocol that fits best.  For instance decoding with one
protocol might produce a scancode that isn't assigned to any key, while
another protocol produces an assigned scancode.  Clearly then the latter is
most likely to be correct.  It also possible to have a space/mark length
that is within the allowable tolerances for one remote, but is even closer
another remote.  You don't want to just find *a* match, you want to find
the *best* match.

The in kernel code in v4l is very simple in that it is only designed to
work with one procotol and one remote.  Once you have multiple remotes of
any type things become much more complicted.  Keep in mind that remotes
that aren't even intended to be used with the computer but are used in the
same room will still be received by the receiver.  It's not enough to
decode the signals you expect to receive, you must also not get confused by
random signals destined for somewhere else.
--
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Trent Piepho
On Thu, 26 Nov 2009, Mauro Carvalho Chehab wrote:
  lircd supports input layer interface. Yet, patch 3/3 exports both devices
  that support only pulse/space raw mode and devices that generate scan
  codes via the raw mode interface. It does it by generating artificial
  pulse codes.
 
  Nonsense! There's no generation of artificial pulse codes in the drivers.
  The LIRC interface includes ways to pass decoded IR codes of arbitrary
  length to userspace.

 I might have got wrong then a comment in the middle of the
 imon_incoming_packet() of the SoundGraph iMON IR patch:

 + /*
 +  * Translate received data to pulse and space lengths.
 +  * Received data is active low, i.e. pulses are 0 and
 +  * spaces are 1.

I'm not sure about this specific code, but what is likely
going on here is the waveform is being RLE encoding.

For example, a cx88 receiver has two ways of being connected (without
using an external decoder chip).  One generates an IRQ on each
edge of the signal.  The time between IRQs gives mark/space lengths
which is what lirc expects.  This is how a simple serial port receiver
works too.

Another connections effectivly samples the waveform one bit deep at IIRC
4kHz.  I think that's what the code you are looking at gets.  The code
extracts the edges from the waveform and returns the time between them.  In
effect one is run length encoding a sequence of bits.
--
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Dmitry Torokhov
On Thu, Nov 26, 2009 at 01:16:01AM -0500, Jarod Wilson wrote:
 On Nov 26, 2009, at 12:31 AM, Dmitry Torokhov wrote:
 
  On Mon, Nov 23, 2009 at 11:37:53PM -0500, Jarod Wilson wrote:
  On 11/23/2009 12:37 PM, Dmitry Torokhov wrote:
  On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote:
  Mauro Carvalho Chehabmche...@redhat.com  writes:
  
  Event input has the advantage that the keystrokes will provide an unique
  representation that is independent of the device.
  
  This can hardly work as the only means, the remotes have different keys,
  the user almost always has to provide customized keyfunction mapping.
  
  
  Is it true? I would expect the remotes to have most of the keys to have
  well-defined meanings (unless it is one of the programmable remotes)...
  
  Its the cases like programmable universal remotes that really throw  
  things for a loop. That, and people wanting to use random remote X that  
  came with the amp or tv or set top box, with IR receiver Y.
  
  Right, but still the keys usually do have the well-defined meaning,
 
 Except when they don't. I have two very similar remotes, one that was bundled 
 with a system from CaptiveWorks, and one that was bundled with an Antec Veris 
 IR/LCD (SoundGraph iMON rebrand). Outside of the Antec remote having a mouse 
 pad instead of up/down/left/right/enter, they have an identical layout, and 
 the keys in the same locations on the remotes send the same IR signal. But 
 the button names vary a LOT between the two. So on the DVD key on the Antec 
 and the MUTE key on the CW send the same signal. Same with Audio vs. Eject, 
 TV vs. History, etc. Moral of the story is that not all IR protocols spell 
 things out particularly well for what a given code should actually mean.

I guess we are talking about different things. While the 2 remotes may
use different protocols to communicate and may use the same codes to
mean different things they buttons have well-defined meaning and we
could map that to input keycodes. Then what is left is to load the
proper mapping for particular device into the kernel. This can be done
either automatically (when we know the mapping) or with the help of the
user (owner of the system).

 
  teh
  issue is in mapping raw code to the appropriate keycode. This can be
  done either by lirc config file (when lirc is used) or by some other
  means.
 
 The desire to map a button press to multiple keystrokes isn't uncommon 
 either, though I presume that's doable within the input layer context too.

No, at present we expect 1:1 button-event mapping leaving macro
expansion (i.e. KEY_PROG1 - do some multi-step sequence to
userspace).

-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Dmitry Torokhov
On Wed, Nov 25, 2009 at 10:58:29PM +0100, Gerd Hoffmann wrote:

 (1) ir code (say rc5) - keycode conversion looses information.

 I think this can easily be addressed by adding a IR event type to the  
 input layer, which could look like this:

   input_event-type  = EV_IR
   input_event-code  = IR_RC5
   input_event-value = rc5 value

 In case the 32bit value is too small we might want send two events  
 instead, with -code being set to IR_code_1 and IR_code_2

 Advantages:
   * Applications (including lircd) can get access to the unmodified
 rc5/rc6/... codes.
   * All the ir-code - keycode mapping magic can be handled by the
 core input layer then.  All the driver needs to do is to pass on
 the information which keymap should be loaded by default (for the
 bundled remote if any).  The configuration can happen in userspace
 (sysfs attribute + udev + small utility in tools/ir/).
   * lirc drivers which get ir codes from the hardware can be converted
 to pure input layer drivers without regressions.  lircd is not
 required any more.


I think we need to separate 2 kinds of applications since they have
different requirements as far as interface goes:

1. Reguilar user-space applications interested in receiving keystrokes
from user and reacting to them. Movie players, CD players, MythTV-like
applications and so on. Those, to my understanding, are not concerned
with the fine details of RC5, RC6, NEC and so forth protocol decoding
and just want to know when to start playing, when to stop and when to
revind. That class of applications is best served by current input layer
since it unifies data coming from IR, keyboards, button devices and so
forth.

2. System applications that are interested in protocol decoding. Those
need interface best suited for IR and nothing else. This protocol is
appears is better kept separate from the evdev input protocol. In case
where we rely solely on such userspace application(s) to perform protocol
decoding we should route input events back to kernel through uinput for
consumption by class 1 applications.


We use this approach for PS/2 (serio allows binding either psmouse/atkbd
or serio_raw to provide alternate interfaces depending on the users
need), USB hid allows raw access as well, maybe we should follow the
suit here.

-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Dmitry Torokhov
On Thu, Nov 26, 2009 at 03:49:13PM -0200, Mauro Carvalho Chehab wrote:
 
 Dmitry,
 
 While lirc is basically a series of input drivers, considering that they have 
 lots
 in common with the input drivers at V4L/DVB and that we'll need to work on
 some glue to merge both, do you mind if I add the lirc drivers at 
 drivers/staging from
 my trees? 
 

Mauro,

I would not mind if you will be pushing it to staging, however I am not
sure we have an agreement on what exactly the interface that we will be
using. I would hate to get something in that will need to be reworked
again.

Thanks.

-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Krzysztof Halasa
Dmitry Torokhov dmitry.torok...@gmail.com writes:

 One remote per
 device only.

 Why would you want more? One physical device usually corresponds to a
 logical device. If you have 2 remotes create 2 devices.

I meant per receiver device.
-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Krzysztof Halasa
Mauro Carvalho Chehab mche...@redhat.com writes:

 Why do you want to replace everything into a single shot?

Why not? It seems simpler to me. We need to change this anyway.

If we change the whole table in a single ioctl, we can easily enumerate
protocols requested and enable then selectively.
But I think it's a minor implementation decision and we don't need to
look at it at this time.
-- 
Krzysztof Halasa
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Dmitry Torokhov
On Fri, Nov 27, 2009 at 01:13:51AM +0100, Krzysztof Halasa wrote:
 Dmitry Torokhov dmitry.torok...@gmail.com writes:
 
  One remote per
  device only.
 
  Why would you want more? One physical device usually corresponds to a
  logical device. If you have 2 remotes create 2 devices.
 
 I meant per receiver device.

There is nothing in input layer that precludes you from creating
multiple input devices per *whatever*. Please, when you are talking
about limitations, specify whether those limitations are applicable to
the input layer, the current implementation of IR in DVB or something
else.

Thanks.

-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Arnd Bergmann
On Friday 27 November 2009 00:19:44 Krzysztof Halasa wrote:
 Mauro Carvalho Chehab mche...@redhat.com writes:
 
  Why do you want to replace everything into a single shot?
 
 Why not? It seems simpler to me. We need to change this anyway.

ioctls with a variable argument length are a pain for 32 bit
emulation and stuff like strace. You either need to encode
the variable length into the ioctl cmd, making it variable
as well, or use a pointer in the data structure, which requires
conversion.

Ideally, ioctl arguments have a constant layout, no pointers
and are at most 64 bits long.

Arnd 
--
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Krzysztof Halasa
Dmitry Torokhov dmitry.torok...@gmail.com writes:

 There is nothing in input layer that precludes you from creating
 multiple input devices per *whatever*.

Of course. I though it was obvious I mean present situation with the
media drivers but I can see now it was far from being obvious.
-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Krzysztof Halasa
Trent Piepho xy...@speakeasy.org writes:

 Then you use the protocol that fits best.  For instance decoding with one
 protocol might produce a scancode that isn't assigned to any key, while
 another protocol produces an assigned scancode.  Clearly then the latter is
 most likely to be correct.

Right.

 It also possible to have a space/mark length
 that is within the allowable tolerances for one remote, but is even closer
 another remote.  You don't want to just find *a* match, you want to find
 the *best* match.

That won't work, the decoders don't calculate quality. And even if they
did, if you have two remotes generating the same e.g. RC5 code, you
won't be able to differentiate between them. Your TV etc. won't do that
either.

 The in kernel code in v4l is very simple in that it is only designed to
 work with one procotol and one remote.  Once you have multiple remotes of
 any type things become much more complicted.

If you're using them at once, sure :-)

 Keep in mind that remotes
 that aren't even intended to be used with the computer but are used in the
 same room will still be received by the receiver.  It's not enough to
 decode the signals you expect to receive, you must also not get confused by
 random signals destined for somewhere else.

This is usually not a problem. My experience is the decoding is very
reliable.
-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Dmitry Torokhov wrote:
 On Thu, Nov 26, 2009 at 03:49:13PM -0200, Mauro Carvalho Chehab wrote:
 Dmitry,

 While lirc is basically a series of input drivers, considering that they 
 have lots
 in common with the input drivers at V4L/DVB and that we'll need to work on
 some glue to merge both, do you mind if I add the lirc drivers at 
 drivers/staging from
 my trees? 

 
 Mauro,
 
 I would not mind if you will be pushing it to staging, however I am not
 sure we have an agreement on what exactly the interface that we will be
 using. I would hate to get something in that will need to be reworked
 again.

I understand your concerns.

IMHO, we should be really careful with API's when migrating from staging to the
right place, but I'm not that much concerned with staging. We already have 
several 
drivers there with bad behaviors and even with some API's there that will go to 
/dev/null.

For example there's a V4L2 driver there (staging/go7007) that has their own 
private
API to handle compressed streams. I won't ack moving it from staging while
it has their own private extensions for something that are part of V4L2 API.

Also, staging drivers without progress for a few kernel cycles will be moved to 
/dev/null,
so I don't see much sense of denying a driver to go there.

Anyway, I'll add it there only when you feel comfortable about that and send us 
your ack.

-

From what I heard on the comments, I think we have already a consensus of some 
points:
1) all IR's should implement the standard evdev interface;
2) IR's with raw interfaces will implement a raw pulse/space IR 
interface. 
The proposal is to use lirc API interface for raw pulse/code TX and RX.

Do you think we'll need to better detail the IR raw interface API before 
accepting 
the patches for staging? If so, what level of details do you want?

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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Jarod Wilson

On 11/26/2009 06:23 PM, Dmitry Torokhov wrote:

On Thu, Nov 26, 2009 at 01:16:01AM -0500, Jarod Wilson wrote:

On Nov 26, 2009, at 12:31 AM, Dmitry Torokhov wrote:


On Mon, Nov 23, 2009 at 11:37:53PM -0500, Jarod Wilson wrote:

On 11/23/2009 12:37 PM, Dmitry Torokhov wrote:

On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote:

Mauro Carvalho Chehabmche...@redhat.com   writes:


Event input has the advantage that the keystrokes will provide an unique
representation that is independent of the device.


This can hardly work as the only means, the remotes have different keys,
the user almost always has to provide customized keyfunction mapping.



Is it true? I would expect the remotes to have most of the keys to have
well-defined meanings (unless it is one of the programmable remotes)...


Its the cases like programmable universal remotes that really throw
things for a loop. That, and people wanting to use random remote X that
came with the amp or tv or set top box, with IR receiver Y.


Right, but still the keys usually do have the well-defined meaning,


Except when they don't. I have two very similar remotes, one that was bundled 
with a system from CaptiveWorks, and one that was bundled with an Antec Veris 
IR/LCD (SoundGraph iMON rebrand). Outside of the Antec remote having a mouse 
pad instead of up/down/left/right/enter, they have an identical layout, and the 
keys in the same locations on the remotes send the same IR signal. But the 
button names vary a LOT between the two. So on the DVD key on the Antec and the 
MUTE key on the CW send the same signal. Same with Audio vs. Eject, TV vs. 
History, etc. Moral of the story is that not all IR protocols spell things out 
particularly well for what a given code should actually mean.


I guess we are talking about different things. While the 2 remotes may
use different protocols to communicate


The remotes use the exact same protocol. Their respective bundled 
receivers however, do translate key presses differently. Perhaps this is 
a bad example though, because both of these remotes came with receivers 
that do onboard decoding. But there's nothing stopping me from wanting 
to use either of these remotes with an mceusb IR transceiver.



and may use the same codes to
mean different things they buttons have well-defined meaning and we
could map that to input keycodes. Then what is left is to load the
proper mapping for particular device into the kernel.


In this case, its not the device, but the remote, that we need a 
different mapping for.



This can be done
either automatically (when we know the mapping) or with the help of the
user (owner of the system).


Yep, that'd work. Just trying to illustrate that the same code doesn't 
always mean anywhere near the same thing from one remote to another.



teh
issue is in mapping raw code to the appropriate keycode. This can be
done either by lirc config file (when lirc is used) or by some other
means.


The desire to map a button press to multiple keystrokes isn't uncommon either, 
though I presume that's doable within the input layer context too.


No, at present we expect 1:1 button-event mapping leaving macro
expansion (i.e. KEY_PROG1 -  do some multi-step sequence to
userspace).


Hm. So ctrl-x, alt-tab, etc. would have to be faked in userspace 
somehow. Bummer.


--
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread hermann pitton

Am Donnerstag, den 26.11.2009, 14:59 -0800 schrieb Trent Piepho:
 On Thu, 26 Nov 2009, Mauro Carvalho Chehab wrote:
   See above. Also, several protocols have a way to check if a keystroke 
   were
   properly received. When handling just one protocol, we can use this to 
   double
   check the key. However, on a multiprotocol mode, we'll need to disable 
   this
   feature.
  
   I don't think so. We can pass the space/mark data to all (configured,
   i.e. with active mapping) protocol handlers at once. Should a check
   fail, we ignore the data. Perhaps another protocol will make some sense
   out of it.
 
  What happens if it succeeds on two protocol handlers?
 
 Then you use the protocol that fits best.  For instance decoding with one
 protocol might produce a scancode that isn't assigned to any key, while
 another protocol produces an assigned scancode.  Clearly then the latter is
 most likely to be correct.  It also possible to have a space/mark length
 that is within the allowable tolerances for one remote, but is even closer
 another remote.  You don't want to just find *a* match, you want to find
 the *best* match.
 
 The in kernel code in v4l is very simple in that it is only designed to
 work with one procotol and one remote.  Once you have multiple remotes of
 any type things become much more complicted.  Keep in mind that remotes
 that aren't even intended to be used with the computer but are used in the
 same room will still be received by the receiver.  It's not enough to
 decode the signals you expect to receive, you must also not get confused by
 random signals destined for somewhere else.

Giving some random living room these days, likely open to the kids
rooms, you have to take that into account.

Another point, if decoding from IRQs generated by the remote, there is
flawed hardware around, needing to poll IRQs in some timely manner to
get it to something at all.

This will break such remotes. Never seen?

For me the first priority is, that existing remotes are not broken.

Don't tell you have done a nice job just now, but are unfortunately in
need of testers ... 

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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Jon Smirl
On Thu, Nov 26, 2009 at 9:28 PM, Jarod Wilson ja...@wilsonet.com wrote:
 No, at present we expect 1:1 button-event mapping leaving macro
 expansion (i.e. KEY_PROG1 -  do some multi-step sequence to
 userspace).

 Hm. So ctrl-x, alt-tab, etc. would have to be faked in userspace somehow.
 Bummer.

That is scripting. Scripting always needs to be done in user space.

In the code I posted there is one evdev device for each configured
remote. Mapped single keycodes are presented on these devices for each
IR burst. There is no device for the IR receiver.  A LIRC type process
could watch these devices and then execute scripts based on the
keycodes reported.

The configfs model is very flexible. You could make a remote that
translates the UP/DOWN buttons of several different remotes into
KEY_UP/DOWN.  That lets several different remotes control the same
app.

Sure it is clunky to play with IR hex codes and keycodes in the
configfs mapping dir. If you don't like it write a GUI app for
manipulating the codes. GUI would then generate a script for udev to
run which builds the configfs entries.

Maybe I should rename those directory entries to app instead of
remote. They contain the mappings from IR hex codes to keycodes that
an app is interested in. Usually there is a 1:1 correspondence between
remote and app but there doesn't have to be.

-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Dmitry Torokhov
On Thu, Nov 26, 2009 at 09:28:51PM -0500, Jarod Wilson wrote:
 On 11/26/2009 06:23 PM, Dmitry Torokhov wrote:
 On Thu, Nov 26, 2009 at 01:16:01AM -0500, Jarod Wilson wrote:
 On Nov 26, 2009, at 12:31 AM, Dmitry Torokhov wrote:

 On Mon, Nov 23, 2009 at 11:37:53PM -0500, Jarod Wilson wrote:
 On 11/23/2009 12:37 PM, Dmitry Torokhov wrote:
 On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote:
 Mauro Carvalho Chehabmche...@redhat.com   writes:

 Event input has the advantage that the keystrokes will provide an 
 unique
 representation that is independent of the device.

 This can hardly work as the only means, the remotes have different keys,
 the user almost always has to provide customized keyfunction mapping.


 Is it true? I would expect the remotes to have most of the keys to have
 well-defined meanings (unless it is one of the programmable remotes)...

 Its the cases like programmable universal remotes that really throw
 things for a loop. That, and people wanting to use random remote X that
 came with the amp or tv or set top box, with IR receiver Y.

 Right, but still the keys usually do have the well-defined meaning,

 Except when they don't. I have two very similar remotes, one that was 
 bundled with a system from CaptiveWorks, and one that was bundled with an 
 Antec Veris IR/LCD (SoundGraph iMON rebrand). Outside of the Antec remote 
 having a mouse pad instead of up/down/left/right/enter, they have an 
 identical layout, and the keys in the same locations on the remotes send 
 the same IR signal. But the button names vary a LOT between the two. So on 
 the DVD key on the Antec and the MUTE key on the CW send the same signal. 
 Same with Audio vs. Eject, TV vs. History, etc. Moral of the story is that 
 not all IR protocols spell things out particularly well for what a given 
 code should actually mean.

 I guess we are talking about different things. While the 2 remotes may
 use different protocols to communicate

 The remotes use the exact same protocol. Their respective bundled  
 receivers however, do translate key presses differently. Perhaps this is  
 a bad example though, because both of these remotes came with receivers  
 that do onboard decoding. But there's nothing stopping me from wanting  
 to use either of these remotes with an mceusb IR transceiver.

 and may use the same codes to
 mean different things they buttons have well-defined meaning and we
 could map that to input keycodes. Then what is left is to load the
 proper mapping for particular device into the kernel.

 In this case, its not the device, but the remote, that we need a  
 different mapping for.

I would say that the remote is the device, not the receiver...


 This can be done
 either automatically (when we know the mapping) or with the help of the
 user (owner of the system).

 Yep, that'd work. Just trying to illustrate that the same code doesn't  
 always mean anywhere near the same thing from one remote to another.

We have the same scenatio with atkbd and various laptops - the
extended keys may use the same scancodes for different keys and we use
DMI data to load the proper keymap. Obviously in case if IRC we won't be
using DMI but something else.


 teh
 issue is in mapping raw code to the appropriate keycode. This can be
 done either by lirc config file (when lirc is used) or by some other
 means.

 The desire to map a button press to multiple keystrokes isn't uncommon 
 either, though I presume that's doable within the input layer context too.

 No, at present we expect 1:1 button-event mapping leaving macro
 expansion (i.e. KEY_PROG1 -  do some multi-step sequence to
 userspace).

 Hm. So ctrl-x, alt-tab, etc. would have to be faked in userspace  
 somehow. Bummer.


What is Ctrl-x? Alt-tab? This are application-specific binding and of
course kernel does not emit these. If there is a distinct action that
needs to be signalled then there [normally] is a keycode for it.

-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Dmitry Torokhov
On Thu, Nov 26, 2009 at 10:08:29PM -0500, Jon Smirl wrote:
 On Thu, Nov 26, 2009 at 9:28 PM, Jarod Wilson ja...@wilsonet.com wrote:
  No, at present we expect 1:1 button-event mapping leaving macro
  expansion (i.e. KEY_PROG1 -  do some multi-step sequence to
  userspace).
 
  Hm. So ctrl-x, alt-tab, etc. would have to be faked in userspace somehow.
  Bummer.
 
 That is scripting. Scripting always needs to be done in user space.
 
 In the code I posted there is one evdev device for each configured
 remote. Mapped single keycodes are presented on these devices for each
 IR burst. There is no device for the IR receiver.  A LIRC type process
 could watch these devices and then execute scripts based on the
 keycodes reported.
 
 The configfs model is very flexible. You could make a remote that
 translates the UP/DOWN buttons of several different remotes into
 KEY_UP/DOWN.  That lets several different remotes control the same
 app.
 
 Sure it is clunky to play with IR hex codes and keycodes in the
 configfs mapping dir. If you don't like it write a GUI app for
 manipulating the codes. GUI would then generate a script for udev to
 run which builds the configfs entries.
 
 Maybe I should rename those directory entries to app instead of
 remote. They contain the mappings from IR hex codes to keycodes that
 an app is interested in. Usually there is a 1:1 correspondence between
 remote and app but there doesn't have to be.
 

Maybe we should revisit Jon's patchset as well. Regretfully I did not
have time to do that when it was submitted the last time.

-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Jon Smirl
On Thu, Nov 26, 2009 at 11:33 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
 In the code I posted there is one evdev device for each configured
 remote. Mapped single keycodes are presented on these devices for each
 IR burst. There is no device for the IR receiver.  A LIRC type process
 could watch these devices and then execute scripts based on the
 keycodes reported.

...

 Maybe we should revisit Jon's patchset as well. Regretfully I did not
 have time to do that when it was submitted the last time.

Consider my patch set a technology demo starting point. It shows a
modern architecture for integrating IR into evdev.  Use the input from
everyone else to turn these concepts into a real design. I wrote the
code for the fun of it, I have no commercial interest in IR. I was
annoyed with how LIRC handled Sony remotes on my home system.

The design is a clean slate implementation of IR for the kernel. No
attempt was made at legacy compatibility. I was familiar with evdev vs
/dev/mouse problems from my work on the X server. Because of working
on X I've also always hated keymaps (that's what drove the configfs
design).

I wish one of the set top box or TV manufacturers would step up and
own this.  They are the ones that would benefit the most. Jarod would
probably be open to some consulting, right?

-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Christoph Bartelmus
Hi Jon,

on 27 Nov 09 at 00:06, Jon Smirl wrote:
[...]
 code for the fun of it, I have no commercial interest in IR. I was
 annoyed with how LIRC handled Sony remotes on my home system.

Can you elaborate on this?
I'm not aware of any issue with Sony remotes.

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


Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Christoph Bartelmus
Hi Mauro,

on 26 Nov 09 at 14:25, Mauro Carvalho Chehab wrote:
 Christoph Bartelmus wrote:
[...]
 But I'm still a bit hesitant about the in-kernel decoding. Maybe it's just
 because I'm not familiar at all with input layer toolset.
[...]
 I hope it helps for you to better understand how this works.

So the plan is to have two ways of using IR in the future which are  
incompatible to each other, the feature-set of one being a subset of the  
other?

When designing the key mapping in the kernel you should be aware that  
there are remotes out there that send a sequence of scan codes for some  
buttons, e.g.
http://lirc.sourceforge.net/remotes/pioneer/CU-VSX159

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


Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-25 Thread Krzysztof Halasa
Andy Walls awa...@radix.net writes:

 I would also note that RC-6 Mode 6A, used by most MCE remotes, was
 developed by Philips, but Microsoft has some sort of licensing interest
 in it and it is almost surely encumbered somwhow:

I don't know about legal problems in some countries but from the
technical POV handling the protocol in the kernel is more efficient
or (/and) simpler.
-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-25 Thread Krzysztof Halasa
Jarod Wilson ja...@wilsonet.com writes:

 The bulk of breakage in lirc I've personally had to deal with has
 mostly come in the form of kernel interface changes, which would
 definitely be mitigated by not having to maintain the drivers
 out-of-tree any longer.

Certainly.

 Now, I'm all for improving things and integrating better with the
 input subsystem, but what I don't really want to do is break
 compatibility with the existing setups on thousands (and thousands?)
 of MythTV boxes around the globe. The lirc userspace can be pretty
 nimble. If we can come up with a shiny new way that raw IR can be
 passed out through an input device, I'm pretty sure lirc userspace can
 be adapted to handle that.

Lirc can already handle input layer. Since both ways require userspace
changes, why not do it the right way the first time? Most of the code
is already written.

 If a new input-layer-based transmit interface is developed, we can
 take advantage of that too. But there's already a very mature lirc
 interface for doing all of this. So why not start with adding things
 more or less as they exist right now and evolve the drivers into an
 idealized form? Getting *something* into the kernel in the first place
 is a huge step in that direction.

What I see as potentially problematic is breaking compatibility multiple
times.
-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-25 Thread Christoph Bartelmus
Hi,

on 25 Nov 09 at 17:53, Krzysztof Halasa wrote:
 Jarod Wilson ja...@wilsonet.com writes:
[...]
 nimble. If we can come up with a shiny new way that raw IR can be
 passed out through an input device, I'm pretty sure lirc userspace can
 be adapted to handle that.

As Trent already pointed out, adding support for raw IR through an input  
device would require a new interface too. You just put the label input  
device on it. This does not make much sense for me.

 Lirc can already handle input layer. Since both ways require userspace
 changes,

I'm not sure what two ways you are talking about. With the patches posted  
by Jarod, nothing has to be changed in userspace.
Everything works, no code needs to be written and tested, everybody is  
happy.

We had exactly the same discussion around one year ago. I've seen no new  
arguements in the current discussion and nobody came up with this shiny  
new way of integrating LIRC into the input layer since last year. Maybe  
it's about time to just accept that the LIRC interface is the way to go.

Can we finally get the patch integrated, please?

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


Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-25 Thread Krzysztof Halasa
l...@bartelmus.de (Christoph Bartelmus) writes:

 I'm not sure what two ways you are talking about. With the patches posted  
 by Jarod, nothing has to be changed in userspace.
 Everything works, no code needs to be written and tested, everybody is  
 happy.

The existing drivers use input layer. Do you want part of the tree to
use existing lirc interface while the other part uses their own
in-kernel (badly broken for example) code to do precisely the same
thing?

We can have a good code for both, or we can end up with badly broken
media drivers and incompatible, suboptimal existing lirc interface
(though most probably much better in terms of quality, especially after
Jarod's work).
-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-25 Thread Jarod Wilson
On Nov 25, 2009, at 11:53 AM, Krzysztof Halasa wrote:

 Jarod Wilson ja...@wilsonet.com writes:
...
 Now, I'm all for improving things and integrating better with the
 input subsystem, but what I don't really want to do is break
 compatibility with the existing setups on thousands (and thousands?)
 of MythTV boxes around the globe. The lirc userspace can be pretty
 nimble. If we can come up with a shiny new way that raw IR can be
 passed out through an input device, I'm pretty sure lirc userspace can
 be adapted to handle that.
 
 Lirc can already handle input layer. Since both ways require userspace
 changes, why not do it the right way the first time? Most of the code
 is already written.

There's obviously still some debate as to what the right way is. :)

And the matter of someone having the time to write the rest of the code that 
would be needed.

 If a new input-layer-based transmit interface is developed, we can
 take advantage of that too. But there's already a very mature lirc
 interface for doing all of this. So why not start with adding things
 more or less as they exist right now and evolve the drivers into an
 idealized form? Getting *something* into the kernel in the first place
 is a huge step in that direction.
 
 What I see as potentially problematic is breaking compatibility multiple
 times.

Ah, but the approach I'd take to converting to in-kernel decoding[*] would be 
this:

1) bring drivers in in their current state
   - users keep using lirc as they always have

2) add in-kernel decoding infra that feeds input layer

3) add option to use in-kernel decoding to existing lirc drivers
   - users can keep using lirc as they always have
   - users can optionally try out in-kernel decoding via a modparam

4) switch the default mode from lirc decode to kernel decode for each lirc 
driver
   - modparam can be used to continue using lirc interface instead

5) assuming users aren't coming at us with pitchforks, because things don't 
actually work reliably with in-kernel decoding, deprecate the lirc interface in 
driver

6) remove lirc interface from driver, its now a pure input device

This would all be on a per-lirc-driver basis, and if/when all decoding could be 
reliably done in-kernel, and/or there was a way other than the lirc interface 
to pass raw IR signals out to userspace, the lirc interface could be removed 
entirely.

And we still need to consider IR transmitters as well. Those are handled quite 
well through the lirc interface, and I've not seen any concrete code (or even 
fully fleshed out ideas) on how IR transmit could be handled in this in-kernel 
decoding world.


[*] assuming, of course, that it was actually agreed upon that in-kernel 
decoding was the right way, the only way, all others will be shot on sight. ;)

-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-25 Thread Jarod Wilson
On Nov 25, 2009, at 12:40 PM, Krzysztof Halasa wrote:

 l...@bartelmus.de (Christoph Bartelmus) writes:
 
 I'm not sure what two ways you are talking about. With the patches posted  
 by Jarod, nothing has to be changed in userspace.
 Everything works, no code needs to be written and tested, everybody is  
 happy.
 
 The existing drivers use input layer. Do you want part of the tree to
 use existing lirc interface while the other part uses their own
 in-kernel (badly broken for example) code to do precisely the same
 thing?

Took me a minute to figure out exactly what you were talking about. You're 
referring to the current in-kernel decoding done on an ad-hoc basis for 
assorted remotes bundled with capture devices, correct?

Admittedly, unifying those and the lirc driven devices hasn't really been on my 
radar.

 We can have a good code for both, or we can end up with badly broken
 media drivers and incompatible, suboptimal existing lirc interface
 (though most probably much better in terms of quality, especially after
 Jarod's work).

Well, is there any reason most of those drivers with 
currently-in-kernel-but-badly-broken decoding can't be converted to use the 
lirc interface if its merged into the kernel? And/or, everything could converge 
on a new in-kernel decoding infra that wasn't badly broken. Sure, there may be 
two separate ways of doing essentially the same thing for a while, but meh. The 
lirc way works NOW for an incredibly wide variety of receivers, transmitters, 
IR protocols, etc.

I do concur that Just Works decoding for bundled remotes w/o having to 
configure anything would be nice, and one way to go about doing that certainly 
is via in-kernel IR decoding. But at the same time, the second you want to use 
something other than a bundled remote, things fall down, and having to do a 
bunch of setkeycode ops seems less optimal than simply dropping an appropriate 
lircd.conf in place.

-- 
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-25 Thread Devin Heitmueller
On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson ja...@wilsonet.com wrote:
 Took me a minute to figure out exactly what you were talking about. You're 
 referring to the current in-kernel decoding done on an ad-hoc basis for 
 assorted remotes bundled with capture devices, correct?

 Admittedly, unifying those and the lirc driven devices hasn't really been on 
 my radar.

This is one of the key use cases I would be very concerned with.  For
many users who have bought tuner products, the bundled remotes work
out-of-the-box, regardless of whether lircd is installed.  I have no
objection so much as to saying well, you have to install the lircd
service now, but there needs to be a way for the driver to
automatically tell lirc what the default remote control should be, to
avoid a regression in functionality.  We cannot go from a mode where
it worked automatically to a mode where now inexperienced users now
have to deal with the guts of getting lircd properly configured.

If such an interface were available, I would see to it that at least
all the devices I have added RC support for will continue to work
(converting the in-kernel RC profiles to lirc RC profiles as needed
and doing the associations with the driver).

The other key thing I don't think we have given much thought to is the
fact that in many tuners, the hardware does RC decoding and just
returns NEC/RC5/RC6 codes.  And in many of those cases, the hardware
has to be configured to know what format to receive.  We probably need
some kernel API such that the hardware can tell lirc what formats are
supported, and another API call to tell the hardware which mode to
operate in.

This is why I think we really should put together a list of use cases,
so that we can see how any given proposal addresses those use cases.
I offered to do such, but nobody seemed really interested in this.

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


  1   2   >