Prev: x86, crypto, Use gas macro for PCLMULQDQ-NI and PSHUFB
Next: [patch 6/8] x86: UV - XPC NULL deref when mesq becomes empty.
From: Krzysztof Halasa on 25 Nov 2009 15:50
Devin Heitmueller <dheitmueller(a)kernellabs.com> writes:

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

For such cases, I wouldn't bother with lirc mode. Input layer + key
mapping with ioctl (probably improved), and lircd can grab events from
input layer if needed.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Gerd Hoffmann on 25 Nov 2009 18:30
>> (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.
>
> Unfortunately with most hardware decoders the code that you get is only
> remotely related to the actual code sent. Most RC-5 decoders strip off
> start bits.

I would include only the actual data bits in the payload anyway.

> Toggle-bits are thrown away. NEC decoders usually don't pass
> through the address part.

Too bad. But information which isn't provided by the hardware can't be
passed up anyway, no matter what kernel/userspace interface is used.
Gone is gone.

> There is no common standard which bit is sent first, LSB or MSB.

Input layer would have to define a bit order. And drivers which get it
the other way from the hardware have to convert. Or maybe signal the
order and the input core then will convert if needed.

> Checksums are thrown away.

Don't include them.

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

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.

> Actually lircd does not even know anything about
> actual protocols. We only distinguish between certain protocol types, like
> Manchester encoded, space encoded, pulse encoded etc. Everything else like
> the actual timing is fully configurable.

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 ;)

cheers,
Gerd

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Andy Walls on 25 Nov 2009 22:40
On Wed, 2009-11-25 at 13:07 -0500, Jarod Wilson wrote:
> On Nov 25, 2009, at 12:40 PM, Krzysztof Halasa wrote:
>
> > lirc(a)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.

It has been on mine. I have been somewhat against the input subsystem
route for unification because it neglects transmitters and appears to
trade the userspace complexity we already have (i.e. LIRC configuration)
for another new (and hence less documented) configuration complexity for
end users.

My strategy for unification goes something like this:

1. Get lirc_dev and the needed supporting headers in the kernel. I will
concede LIRC is not perfect or beautiful, but I'll assert it is feature
complete for all the end user use cases that matter.

2. Encapsulate all the various IR controller hardware handling in
V4L-DVB into v4l_subdevice objects and provide a uniform interface to IR
hardware internally via v4l2_subdev_ir_ops. The exact nature of the IR
hardware is then mostly abstracted away: I2C bus microcontroller,
register block, GPIO line control of discretes devices, etc. can all be
accessed in a somewhat unifrom manner.

3. In conjunction with 2, common IR handling routines that exist in
various drivers already can be broken out: RC-5 protocol handling, etc.

4. Develop an internal interface so the v4l2_subdev object instance for
the IR hardware is exposed through a bridge driver's v4l2_device object.

5. Develop the needed layer between lirc_dev and the v4l2_device object
to connect things up.


That unifies all the IR cats and dogs in V4L-DVB at the low levels and
glues them in a consistent manner to something up top (i.e. lirc_dev)
that already handles Rx, Tx, protocols, keymapping, etc.

My primary desire is to encapsulate or remove the complexity we
currently have in kernel with all the ad-hoc IR hardware handling and
get it unifrom and layered.

The upper level glue to userspace doesn't have to be lirc_dev, but why
not? It's there and the end users are familiair with it. I have
set-top boxes, I need IR Tx.



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

I think all the V4L-DVB IR hardware can be. I have not done sufficient
research on the Serial, USB and other devices to say personally.


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

Also LIRC has had years of requirements collection and refinement of use
cases. Anything new implementation will likely end up converging to the
feature set LIRC already has implemented.



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


>From a big picture perspective I would never see the OS kenrel as a good
place to address usability issues. It seems more logical to fix
usability issues with a decent GUI application and good documentation.
(LIRC needs a configuration GUI!). Expecting IR usability problems to
be eased by the kernel and command line utilties is - well -
optimistic.

I'll add that there are too many factors that can be permuted by the end
user and OEM -- protocols, remote layouts, button codes, PC IR Rx/Tx
hardware, and Set top boxes feeding PC video capture devices -- that
generating defaults that "Just Work" is a generally unsolvable problem.


Regards,
Andy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Andy Walls on 25 Nov 2009 23:00
On Wed, 2009-11-25 at 13:20 -0500, Devin Heitmueller wrote:
> On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson <jarod(a)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.

Please think about how we would need to augment the v4l_subdev_ir_ops:

http://linuxtv.org/hg/v4l-dvb/file/74ad936bcca2/linux/include/media/v4l2-subdev.h#l246
http://linuxtv.org/hg/v4l-dvb/file/74ad936bcca2/linux/include/media/v4l2-subdev.h#l305
http://linuxtv.org/hg/v4l-dvb/file/74ad936bcca2/linux/include/media/v4l2-subdev.h#l27

I think encapsulation of the various IR devices under V4L-DVB into
v4l_subdevices can facilitate your suggestions.


The CX23888 IR subdevice code configures itself to a single default
setup for Tx and Rx:

http://linuxtv.org/hg/v4l-dvb/file/74ad936bcca2/linux/drivers/media/video/cx23885/cx23888-ir.c#l1192
http://linuxtv.org/hg/v4l-dvb/file/74ad936bcca2/linux/drivers/media/video/cx23885/cx23888-ir.c#l1211

but there isn't a reason V4L2 IR subdevices couldn't configure to a per
"product" defaults based on information about the detected card from the
main bridge driver code.

Regards,
Andy

> 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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Andy Walls on 25 Nov 2009 23:30
On Wed, 2009-11-25 at 22:58 +0100, Gerd Hoffmann wrote:
> On 11/25/09 19:20, Devin Heitmueller wrote:
> > On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson<jarod(a)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 ...
>
> > 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 bet this simply isn't going to change.
>
> > 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.
>
> *Requiring* lircd for the current in-kernel drivers doesn't make sense
> at all. Allowing lircd being used so it can do some more advanced stuff
> makes sense though.
>
> > 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.
>
> Lets have a look at the problems the current input layer bits have
> compared to lirc:
>
>
> (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

RC-6 Mode 6A can be up to 67 bits:

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

(This page is slightly wrong, there is some data coded in the header
such as the RC-6 Mode, but I can't remeber if it's biphase or not.)

> 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.
>
> (2) input layer doesn't give access to the raw samples.
>
> Not sure how to deal with that best. Passing them through the input
> layer would certainly be possible to hack up. But what would be the
> point? The input layer wouldn't do any processing on them. It wouldn't
> buy us much. So we might want to simply stick with todays lirc
> interface for the raw samples.
>
> Drivers which support both ir codes (be it by hardware or by in-kernel
> decoding) and raw samples would register two devices then, one input
> device and one lirc device. It would probably a good idea to stop
> sending events to the input layer as soon as someone (most likely lircd)
> opens the lirc device to avoid keystrokes showing up twice.
>
> By default the in-kernel bits will be at work, but optionally you can
> have lircd grab the raw samples and do fancy advanced decoding.

(2a) Input layer doesn't help with raw samples:

So now what about devices that don't produce codes at all, but simply
pulse width measurements? Where's the infrastrucutre to perform low
pass filtering to get rid of glitches and to perform oversampling to
deal with pulse jitter, so that adding a new IR device isn't a pain
incurred per driver?

I was quite dismayed at how much I had to reimplement here, just for
RC-5 for the sake of the input layer and having a remote "Just Work":

http://linuxtv.org/hg/v4l-dvb/file/74ad936bcca2/linux/drivers/media/video/cx23885/cx23885-input.c

lirc does all that stuff in spades.


> (3) input layer doesn't allow transmitting IR codes.
>
> If we keep the lirc interface for raw samples anyway, then we can keep
> it for sending too, problem solved ;) How does sending hardware work
> btw? Do they all accept just raw samples? Or does some hardware also
> accept ir-codes?

The Conexant chips' integrated IR Tx hardware expects a series of pulse
widths and a flag for mark or space with each width.

I'd have to research other implementations.

Regards,
Andy

> cheers,
> Gerd


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12
Prev: x86, crypto, Use gas macro for PCLMULQDQ-NI and PSHUFB
Next: [patch 6/8] x86: UV - XPC NULL deref when mesq becomes empty.