Hi,
on 12 Nov 08 at 14:39, J.R. Mauro wrote:
[...]
> On Wed, Nov 5, 2008 at 3:07 PM, Jon Smirl <[email protected]> wrote:
>> On Wed, Nov 5, 2008 at 2:59 PM, J.R. Mauro <[email protected]> wrote:
>>> On Wed, Nov 5, 2008 at 2:47 PM, Jon Smirl <[email protected]> wrote:
>>>> New release of in-kernel IR support implementing evdev support. The goal
>>>> of in-kernel IR is to integrate IR events into the evdev input event
>>>> queue and maintain ordering of events from all input devices. Still
>>>> looking for help with this project.
>>> (Forgive me if this has already been asked or dealt with)
>>> Have you contacted the LIRC developers? Is there any overlap between
>>> your projects?
>> The LIRC people know about this. Pieces of the code are coming from
>> the LIRC source base and being reworked for kernel inclusion.
> Great, it's nice to see there's cooperation.
LOL. There's just a small omission from Jon's side...
Yes, LIRC people know about this. And Jon has a no-go from me.
Decoding IR protocols in-kernel is the wrong way IMHO and this will not be
supported by LIRC as long as I maintain LIRC.
It's simply not possible to decode all existing IR protocols and LIRC just
stores the timing data for these protocols as-is without trying to decode
them. With the in-kernel decoding approach these remotes cannot be
supported. I'm not willing to sacrifice the support for these even though
they only consist of a very small fraction of remotes in use.
Christoph
Christoph Bartelmus wrote:
> Hi,
>
> on 12 Nov 08 at 14:39, J.R. Mauro wrote:
> [...]
>> On Wed, Nov 5, 2008 at 3:07 PM, Jon Smirl <[email protected]> wrote:
>>> On Wed, Nov 5, 2008 at 2:59 PM, J.R. Mauro <[email protected]> wrote:
>>>> On Wed, Nov 5, 2008 at 2:47 PM, Jon Smirl <[email protected]> wrote:
>>>>> New release of in-kernel IR support implementing evdev support. The goal
>>>>> of in-kernel IR is to integrate IR events into the evdev input event
>>>>> queue and maintain ordering of events from all input devices. Still
>>>>> looking for help with this project.
>
>>>> (Forgive me if this has already been asked or dealt with)
>
>>>> Have you contacted the LIRC developers? Is there any overlap between
>>>> your projects?
>
>>> The LIRC people know about this. Pieces of the code are coming from
>>> the LIRC source base and being reworked for kernel inclusion.
>
>> Great, it's nice to see there's cooperation.
>
> LOL. There's just a small omission from Jon's side...
> Yes, LIRC people know about this. And Jon has a no-go from me.
>
> Decoding IR protocols in-kernel is the wrong way IMHO and this will not be
> supported by LIRC as long as I maintain LIRC.
> It's simply not possible to decode all existing IR protocols and LIRC just
> stores the timing data for these protocols as-is without trying to decode
> them. With the in-kernel decoding approach these remotes cannot be
> supported. I'm not willing to sacrifice the support for these even though
> they only consist of a very small fraction of remotes in use.
+1
I agree completely.
This way we can make lirc to recognize any remote.
Don't yet have a general receiver, but when I have one, I would like to use my remotes,
and who knows what protocols they use...
Best solution is to make new input layer message, a raw PCM data.
or, you can even keep the daemon, but make it inject input events back to input system.
The only think I don't like at all about lirc is that you need special library to talk to it
while I want remotes to be used as a keyboards.
Btw, one can write a lirc client that does the above, but this is hackish.
Some standard ir protocols can be decoded in kernel, but there should be standard (not debug) way
to do so in userspace.
Just my .02 cents,
Best regards,
Maxim Levitsky
>
> Christoph
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Thu 2008-11-13 00:09:00, Christoph Bartelmus wrote:
> Hi,
>
> on 12 Nov 08 at 14:39, J.R. Mauro wrote:
> [...]
> > On Wed, Nov 5, 2008 at 3:07 PM, Jon Smirl <[email protected]> wrote:
> >> On Wed, Nov 5, 2008 at 2:59 PM, J.R. Mauro <[email protected]> wrote:
> >>> On Wed, Nov 5, 2008 at 2:47 PM, Jon Smirl <[email protected]> wrote:
> >>>> New release of in-kernel IR support implementing evdev support. The goal
> >>>> of in-kernel IR is to integrate IR events into the evdev input event
> >>>> queue and maintain ordering of events from all input devices. Still
> >>>> looking for help with this project.
>
> >>> (Forgive me if this has already been asked or dealt with)
>
> >>> Have you contacted the LIRC developers? Is there any overlap between
> >>> your projects?
>
> >> The LIRC people know about this. Pieces of the code are coming from
> >> the LIRC source base and being reworked for kernel inclusion.
>
> > Great, it's nice to see there's cooperation.
>
> LOL. There's just a small omission from Jon's side...
> Yes, LIRC people know about this. And Jon has a no-go from me.
>
> Decoding IR protocols in-kernel is the wrong way IMHO and this will not be
> supported by LIRC as long as I maintain LIRC.
Time to fork lirc...?
Can you elaborate? I don't see why IR remotes deserve special
handling. I'd expect to just plug in the receiver and have it work as
/dev/input/*.
> It's simply not possible to decode all existing IR protocols and LIRC just
> stores the timing data for these protocols as-is without trying to decode
> them. With the in-kernel decoding approach these remotes cannot be
> supported. I'm not willing to sacrifice the support for these even though
> they only consist of a very small fraction of remotes in use.
So you make it suck for everyone just because few obscure IR
remotes. Perfect enemy of good, I'd say :-(.
Can we merge the common ones into the kernel, while still keeping the
obscure ones in userspace using uinput or something?
I don't see why Jon's work bothers you. He's trying to do the right
support for the common remotes. That seems like a net plus to me, and
you can still keep the obscure ones in userland.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Sat, Nov 15, 2008 at 6:58 AM, Pavel Machek <[email protected]> wrote:
> On Thu 2008-11-13 00:09:00, Christoph Bartelmus wrote:
>> Hi,
>>
>> on 12 Nov 08 at 14:39, J.R. Mauro wrote:
>> [...]
>> > On Wed, Nov 5, 2008 at 3:07 PM, Jon Smirl <[email protected]> wrote:
>> >> On Wed, Nov 5, 2008 at 2:59 PM, J.R. Mauro <[email protected]> wrote:
>> >>> On Wed, Nov 5, 2008 at 2:47 PM, Jon Smirl <[email protected]> wrote:
>> >>>> New release of in-kernel IR support implementing evdev support. The goal
>> >>>> of in-kernel IR is to integrate IR events into the evdev input event
>> >>>> queue and maintain ordering of events from all input devices. Still
>> >>>> looking for help with this project.
>>
>> >>> (Forgive me if this has already been asked or dealt with)
>>
>> >>> Have you contacted the LIRC developers? Is there any overlap between
>> >>> your projects?
>>
>> >> The LIRC people know about this. Pieces of the code are coming from
>> >> the LIRC source base and being reworked for kernel inclusion.
>>
>> > Great, it's nice to see there's cooperation.
>>
>> LOL. There's just a small omission from Jon's side...
>> Yes, LIRC people know about this. And Jon has a no-go from me.
>>
>> Decoding IR protocols in-kernel is the wrong way IMHO and this will not be
>> supported by LIRC as long as I maintain LIRC.
>
> Time to fork lirc...?
>
> Can you elaborate? I don't see why IR remotes deserve special
> handling. I'd expect to just plug in the receiver and have it work as
> /dev/input/*.
>
>> It's simply not possible to decode all existing IR protocols and LIRC just
>> stores the timing data for these protocols as-is without trying to decode
>> them. With the in-kernel decoding approach these remotes cannot be
>> supported. I'm not willing to sacrifice the support for these even though
>> they only consist of a very small fraction of remotes in use.
>
> So you make it suck for everyone just because few obscure IR
> remotes. Perfect enemy of good, I'd say :-(.
>
> Can we merge the common ones into the kernel, while still keeping the
> obscure ones in userspace using uinput or something?
>
> I don't see why Jon's work bothers you. He's trying to do the right
> support for the common remotes. That seems like a net plus to me, and
> you can still keep the obscure ones in userland.
We manage to have both kernelspace and userspace USB drivers. I think
that would be the right approach here, especially since whole classes
of some remotes change model to model. Apple remotes are an example of
this: you have to figure out what different signal each new model
sends and it is really nice for the user to be able to do this and put
it in a config file and not have to wait for the next kernel version.
Finding the middle ground here is probably the sanest course.
>
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>
Hi Pavel,
on 15 Nov 08 at 12:58, Pavel Machek wrote:
[...]
> On Thu 2008-11-13 00:09:00, Christoph Bartelmus wrote:
>> Hi,
>>
>> on 12 Nov 08 at 14:39, J.R. Mauro wrote:
>> [...]
>>> On Wed, Nov 5, 2008 at 3:07 PM, Jon Smirl <[email protected]> wrote:
>>>> On Wed, Nov 5, 2008 at 2:59 PM, J.R. Mauro <[email protected]> wrote:
>>>>> On Wed, Nov 5, 2008 at 2:47 PM, Jon Smirl <[email protected]> wrote:
>>>>>> New release of in-kernel IR support implementing evdev support. The
>>>>>> goal of in-kernel IR is to integrate IR events into the evdev input
>>>>>> event queue and maintain ordering of events from all input devices.
>>>>>> Still looking for help with this project.
>>
>>>>> (Forgive me if this has already been asked or dealt with)
>>
>>>>> Have you contacted the LIRC developers? Is there any overlap between
>>>>> your projects?
>>
>>>> The LIRC people know about this. Pieces of the code are coming from
>>>> the LIRC source base and being reworked for kernel inclusion.
>>
>>> Great, it's nice to see there's cooperation.
>>
>> LOL. There's just a small omission from Jon's side...
>> Yes, LIRC people know about this. And Jon has a no-go from me.
>>
>> Decoding IR protocols in-kernel is the wrong way IMHO and this will not be
>> supported by LIRC as long as I maintain LIRC.
> Time to fork lirc...?
This wouldn't be a fork. It has nothing to do with how LIRC currently is
working.
> Can you elaborate? I don't see why IR remotes deserve special
> handling. I'd expect to just plug in the receiver and have it work as
> /dev/input/*.
>
>> It's simply not possible to decode all existing IR protocols and LIRC
just
>> stores the timing data for these protocols as-is without trying to decode
>> them. With the in-kernel decoding approach these remotes cannot be
>> supported. I'm not willing to sacrifice the support for these even though
>> they only consist of a very small fraction of remotes in use.
> So you make it suck for everyone just because few obscure IR
> remotes. Perfect enemy of good, I'd say :-(.
Watch your words. This is getting personal.
Who is telling you that LIRC cannot work like simply plugging in the
receiver and start using the remote?
You can have LIRC setup to decode all common remote control protocols.
It's just a matter of proper packaging and pre-configuration.
You don't have to write a single line of code for this (I still have to
add uinput support, though, which I probably would have done by now, if I
weren't busy writing posts like this).
> Can we merge the common ones into the kernel, while still keeping the
> obscure ones in userspace using uinput or something?
Why do you want to complicate things even more. When you have an obscure
protocol, you have to use LIRC style kernel drivers anyway. Why not use
them for all protocols if you need them anyway?
Everyone seems to be so focussed on the input layer, that he does not even
consider that it might not be the right approach for all cases.
> I don't see why Jon's work bothers you. He's trying to do the right
> support for the common remotes. That seems like a net plus to me, and
> you can still keep the obscure ones in userland.
Jon's code and the LIRC approach exclude each other. It does not make
sense to have both in the kernel. There have been attempts to clean up
LIRC code to be included in the kernel. The current discussion lessens my
hope that this will happen anytime soon.
The decision to include some IR support using the Linux input layer some
time ago has forced *me* to add support for this in LIRC and explain to
people why for some devices they need LIRC drivers, and for some they need
the kernel drivers, and for other configurations they have to explicitly
disable the kernel drivers and replace them by LIRC drivers, etc.
I'm just telling you now, that I will not do this work again for the
drivers in question.
Christoph
On Sun, 23 Nov 2008, Christoph Bartelmus wrote:
> You can have LIRC setup to decode all common remote control protocols.
> It's just a matter of proper packaging and pre-configuration. You don't
> have to write a single line of code for this (I still have to add uinput
> support, though, which I probably would have done by now, if I weren't
> busy writing posts like this).
Just a question -- how much is the situation different to what we
currently have for HID devices?
For these, we currently have common code, that is able to handle all the
"normal" devices by default, that are fully compliant with the HID
standard.
For the devices that don't behave that well, we have specialized drivers,
that use all the generic HID infrastructure to handle the
standard-compliant behavior of the device and allows the specialized
drivers to implement only the parts that violate standard.
It's pretty lightweight and seems to work well. Wouldn't this work also
for LIRC drivers?
--
Jiri Kosina
SUSE Labs
Hi,
on 23 Nov 08 at 21:33, Jiri Kosina wrote:
> On Sun, 23 Nov 2008, Christoph Bartelmus wrote:
>> You can have LIRC setup to decode all common remote control protocols.
>> It's just a matter of proper packaging and pre-configuration. You don't
>> have to write a single line of code for this (I still have to add uinput
>> support, though, which I probably would have done by now, if I weren't
>> busy writing posts like this).
> Just a question -- how much is the situation different to what we
> currently have for HID devices?
>
> For these, we currently have common code, that is able to handle all the
> "normal" devices by default, that are fully compliant with the HID
> standard.
> For the devices that don't behave that well, we have specialized drivers,
> that use all the generic HID infrastructure to handle the
> standard-compliant behavior of the device and allows the specialized
> drivers to implement only the parts that violate standard.
>
> It's pretty lightweight and seems to work well. Wouldn't this work also
> for LIRC drivers?
No. Unlike with HID devices, with most IR receivers you can use any
remote. In LIRC we write drivers for the receivers and don't care about
the remote, which is handled in userspace. The suggested approach would
move both receiver and remote handling into kernel space (actually only
part of it because many receivers have userspace drivers, so both receiver
and remote handling must be done in userspace anyway for these receivers).
Christoph
On Sun, Nov 23, 2008 at 5:28 PM, Christoph Bartelmus <[email protected]> wrote:
> Hi,
>
> on 23 Nov 08 at 21:33, Jiri Kosina wrote:
>> On Sun, 23 Nov 2008, Christoph Bartelmus wrote:
>
>>> You can have LIRC setup to decode all common remote control protocols.
>>> It's just a matter of proper packaging and pre-configuration. You don't
>>> have to write a single line of code for this (I still have to add uinput
>>> support, though, which I probably would have done by now, if I weren't
>>> busy writing posts like this).
>
>> Just a question -- how much is the situation different to what we
>> currently have for HID devices?
>>
>> For these, we currently have common code, that is able to handle all the
>> "normal" devices by default, that are fully compliant with the HID
>> standard.
>> For the devices that don't behave that well, we have specialized drivers,
>> that use all the generic HID infrastructure to handle the
>> standard-compliant behavior of the device and allows the specialized
>> drivers to implement only the parts that violate standard.
>>
>> It's pretty lightweight and seems to work well. Wouldn't this work also
>> for LIRC drivers?
>
> No. Unlike with HID devices, with most IR receivers you can use any
> remote. In LIRC we write drivers for the receivers and don't care about
> the remote, which is handled in userspace. The suggested approach would
> move both receiver and remote handling into kernel space (actually only
> part of it because many receivers have userspace drivers, so both receiver
> and remote handling must be done in userspace anyway for these receivers).
Now that I've worked on this for a while, I'm moving towards putting
all of the IR drivers in the kernel. Putting them in the kernel
collects them in a single place where they can't get lost and they
will be maintained on all archs. Sure you can write these drivers in
user space too. But they are so small (10-20K), they are hardly
noticeable in the kernel when compared to a 4MB Nvidia device driver.
I'm also a big fan of using existing kernel interfaces and not
building new ones. Evdev, sysfs and configfs can implement everything
IR needs and all of them are pre-existing APIs.
The code I'm post is not being marked for inclusion in the kernel. It
is being posted RFC - request for comment. Various features aren't
implement (repeat, more protocol engines, etc). There are bugs too.
After I added configfs support I discovered that interrupt handling
needs to be altered since configfs was being called from interrupt
context and that;s not allowed. I'm traveling now and will fix it when
I get back next week.
I'd like to get some input on the general design but so far nobody
have commented on the design.
>
> Christoph
>
--
Jon Smirl
[email protected]
Hi!
> Who is telling you that LIRC cannot work like simply plugging in the
> receiver and start using the remote?
Well, I don't have to install special userland to make USB keyboard to
work, and I don't see why remote controls should be different.
> You can have LIRC setup to decode all common remote control protocols.
> It's just a matter of proper packaging and pre-configuration.
...which distributions don't generally do because they avoid
out-of-tree patches...?
> > Can we merge the common ones into the kernel, while still keeping the
> > obscure ones in userspace using uinput or something?
>
> Why do you want to complicate things even more. When you have an obscure
> protocol, you have to use LIRC style kernel drivers anyway. Why not use
> them for all protocols if you need them anyway?
It is more complex in the obscure case, agreed; but the common case
gets simpler and I believe tradeoff is worth it.
> Everyone seems to be so focussed on the input layer, that he does not even
> consider that it might not be the right approach for all cases.
Remote controls do look like keyboards; that's why people want to use
input layer.
Unlike normal keyboards, 'tcpdump' or 'irdump' makes a lot of sense
for remote controls, but so what?
> > support for the common remotes. That seems like a net plus to me, and
> > you can still keep the obscure ones in userland.
>
> Jon's code and the LIRC approach exclude each other. It does not make
> sense to have both in the kernel. There have been attempts to clean up
> LIRC code to be included in the kernel. The current discussion lessens my
> hope that this will happen anytime soon.
I don't see why we could not use Jon's code for common remotes decoded
mostly by hw, and your code for the obscure cases.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi,
>> Can we merge the common ones into the kernel, while still keeping the
>> obscure ones in userspace using uinput or something?
>
> Why do you want to complicate things even more.
Reality check please. It already is that complicated. We have IR
kernel drivers today.
> The decision to include some IR support using the Linux input layer some
> time ago has forced *me* to add support for this in LIRC and explain to
> people why for some devices they need LIRC drivers, and for some they need
> the kernel drivers, and for other configurations they have to explicitly
> disable the kernel drivers and replace them by LIRC drivers, etc.
The only way to get out of this situation long-term is to get advanced
IR support into the mainline kernel.
It doesn't matter how that actually looks like. Could be pretty much
like todays lirc drivers. Could be some input layer extention for
receiving/sending raw IR codes. Could be something completely different
such as using the tty layer for that. That has to be discussed and
agreed on.
What *does* matter is being in mainline. lirc not being in mainline was
*the* major reason for me to use the input layer to handle TV card IR
support. Having a in-tree driver depending on a out-of-tree subsystem
for IR is a major pain.
It is certainly a good thing to have only *one* way to handle IR
remotes. But the kernel side of that way *must* be in mainline.
Everything else simply isn't going to fly.
cheers,
Gerd
On Tue, Dec 2, 2008 at 5:00 PM, Gerd Hoffmann <[email protected]> wrote:
> Hi,
>
>>> Can we merge the common ones into the kernel, while still keeping the
>>> obscure ones in userspace using uinput or something?
>>
>> Why do you want to complicate things even more.
>
> Reality check please. It already is that complicated. We have IR
> kernel drivers today.
>
>> The decision to include some IR support using the Linux input layer some
>> time ago has forced *me* to add support for this in LIRC and explain to
>> people why for some devices they need LIRC drivers, and for some they need
>> the kernel drivers, and for other configurations they have to explicitly
>> disable the kernel drivers and replace them by LIRC drivers, etc.
>
> The only way to get out of this situation long-term is to get advanced
> IR support into the mainline kernel.
We at least need a unified place for drivers, or unified support for
those drivers that must be put in userspace, a la usbfs and libusb.
>
> It doesn't matter how that actually looks like. Could be pretty much
> like todays lirc drivers. Could be some input layer extention for
> receiving/sending raw IR codes. Could be something completely different
> such as using the tty layer for that. That has to be discussed and
> agreed on.
Agreed. And we need to make sure the discussion part actually happens
because once a decision is made, it's hard to correct bad choices.
I would think that an input layer extension would be best because,
e.g. Apple remotes are changed around all the time and, while
functioning the same and having the same form, they send very very
slightly different codes, and I think we would want a way to keep this
really flexible so we just update a quirks table or something to that
effect. I don't know if we're already trying to do that (if we are,
hooray, I'll go away now) but I think it's a good idea.
>
> What *does* matter is being in mainline. lirc not being in mainline was
> *the* major reason for me to use the input layer to handle TV card IR
> support. Having a in-tree driver depending on a out-of-tree subsystem
> for IR is a major pain.
>
> It is certainly a good thing to have only *one* way to handle IR
> remotes. But the kernel side of that way *must* be in mainline.
> Everything else simply isn't going to fly.
One way or a hybrid way to address everyone's concerns. I don't see
why this has to be ALL kernel or ALL userspace. I would think it could
be both and still be clean.
>
> cheers,
> Gerd
>
>
>
Hi Pavel,
on 23 Nov 08 at 19:01, Pavel Machek wrote:
[...]
>>> support for the common remotes. That seems like a net plus to me, and
>>> you can still keep the obscure ones in userland.
>>
>> Jon's code and the LIRC approach exclude each other. It does not make
>> sense to have both in the kernel. There have been attempts to clean up
>> LIRC code to be included in the kernel. The current discussion lessens my
>> hope that this will happen anytime soon.
> I don't see why we could not use Jon's code for common remotes decoded
> mostly by hw, and your code for the obscure cases.
Ok, how about this:
there's one common point in lirc_dev where all IR timing data is handled.
Jon's code can grab the data at this point and feed it into its state
machine. That way there's no need to change any of the existing drivers.
And we all work together to get this stuff ready for inclusion into the
kernel.
Christoph
On Tue 2008-12-02 19:00:00, Christoph Bartelmus wrote:
> Hi Pavel,
>
> on 23 Nov 08 at 19:01, Pavel Machek wrote:
> [...]
> >>> support for the common remotes. That seems like a net plus to me, and
> >>> you can still keep the obscure ones in userland.
> >>
> >> Jon's code and the LIRC approach exclude each other. It does not make
> >> sense to have both in the kernel. There have been attempts to clean up
> >> LIRC code to be included in the kernel. The current discussion lessens my
> >> hope that this will happen anytime soon.
>
> > I don't see why we could not use Jon's code for common remotes decoded
> > mostly by hw, and your code for the obscure cases.
>
> Ok, how about this:
> there's one common point in lirc_dev where all IR timing data is handled.
> Jon's code can grab the data at this point and feed it into its state
> machine. That way there's no need to change any of the existing drivers.
> And we all work together to get this stuff ready for inclusion into the
> kernel.
Yes, that sounds sane.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi,
>> The only way to get out of this situation long-term is to get advanced
>> IR support into the mainline kernel.
>
> We at least need a unified place for drivers, or unified support for
> those drivers that must be put in userspace, a la usbfs and libusb.
That isn't good enougth. That unified place must be mainline (for the
kernel stuff). Userland bits can continue to live in the lirc package,
that isn't a problem.
>> It is certainly a good thing to have only *one* way to handle IR
>> remotes. But the kernel side of that way *must* be in mainline.
>> Everything else simply isn't going to fly.
>
> One way or a hybrid way to address everyone's concerns. I don't see
> why this has to be ALL kernel or ALL userspace.
It hasn't to be all kernel or all userspace.
But all kernel bits must be in mainline.
> I would think it could
> be both and still be clean.
Sure. We can even support both ways in the very same driver. I'll grab
a piece of hardware I know of as example: cx88-based TV cards:
* The hardware gives you the raw IR samples.
* The kernel takes them, decodes them and sends the input layer way
to user. The remote bundled with the TV card works fine. Which
is what probably 95% of the users need.
* In theory you can decode *any* remote IR codes. In practice you
can't because there is no way to get the raw IR samples to userspace
where lircd can handle them.
Ok, what are the options to fix the latter?
* lirc would do the trick. Doesn't fly though due to cx88 being
mainline and lirc (kernel drivers) being out-of-tree.
* input layer extension for raw IR codes. Doesn't exist (yet?).
* something completely different ...
Then you can have cx88 register both within the input layer (for the
bundled remote) and in the new raw-ir-codes subsystem. Someone (say
lircd) opening the raw IR interface will make the in-kernel decoding
stop. You are done ;)
cheers,
Gerd