[RFC] What are the goals for the architecture of an in-kernel IR system?
Jon Smirl
<chri...@bartelmus.de> wrote:
> 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?
Take advantage of the fact that we don't have a twenty year old legacy
API already in the kernel. Design an IR API that uses current kernel
systems. Christoph, ignore the code I wrote and make a design proposal
that addresses these goals...
1) Unified input in Linux using evdev. IR is on equal footing with
mouse and keyboard.
2) plug and play for basic systems - you only need an external app for scripting
3) No special tools - use mkdir, echo, cat, shell scripts to build maps
4) Use of modern Linux features like sysfs, configfs and udev.
5) Direct multi-app support - no daemon
6) Hide timing data from user as much as possible.
What are other goals for this subsystem?
Maybe we decide to take the existing LIRC system as is and not
integrate it into the input subsystem. But I think there is a window
here to update the LIRC design to use the latest kernel features. We
don't want to build another /dev/mouse and have to rip it out in five
years.
>
> 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
This is good input.
--
Jon Smirl
jons...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andy Walls
> On Fri, Nov 27, 2009 at 2:45 AM, Christoph Bartelmus
> <chri...@bartelmus.de> wrote:
> > 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?
>
> Take advantage of the fact that we don't have a twenty year old legacy
> API already in the kernel. Design an IR API that uses current kernel
> systems. Christoph, ignore the code I wrote and make a design proposal
> that addresses these goals...
Jon,
It's good to have clear, sensible goals. I'd also like to have
concurrence on what are driving requirements vs. nice-to-have's and also
on priorities.
> 1) Unified input in Linux using evdev. IR is on equal footing with
> mouse and keyboard.
Sounds fine. I think some of the discussion so far indicates the devil
may be in the details. I understand the driving requirement is to avoid
user(?) problems experienced in the past with PS/2 keyboards, etc.
> 2) plug and play for basic systems - you only need an external app for scripting
I concur. Users needing hardware to "Just Work" is *the* driving
requirment for in kernel IR from the discussion. I would only say that
you may not need any application for the default configuration on basic
systems.
> 3) No special tools - use mkdir, echo, cat, shell scripts to build maps
Sounds fine. I also was a user who used setkeys, loadkeys, et. al. once
years ago, and can't remeber for the life of me why I had to do so or
how they work anymore.
> 4) Use of modern Linux features like sysfs, configfs and udev.
I'm not sure this is strictly driven by anything; it's an implementation
decision stated in advance. One uses features, if one needs them.
> 5) Direct multi-app support - no daemon
I understand the rationale for this to really be a desire for minimal
userspace components. If you think/know that the input system can
multiplex or multicast events in a sane way for applications, then I
suppose it's feasible.
I don't hear users asking for minimal userspace components, as their
dsitribution packaging system usually handles this for them. I suspect
this is mostly driven by kernel developers or embedded systems
developers.
> 6) Hide timing data from user as much as possible.
I do not strictly agree with this. I understand this goal is to
insulate users from the low level details of IR protocols. I think that
hinders users' ability to solve or diagnose problems on their own. Some
people like details and flexible control. I think users being able to
report about timing data of unknown remotes or protocols has value as
well.
> What are other goals for this subsystem?
7. Support IR transmit by applications.
8. Support IR transmit without using special applications - just cat,
mkdir, shell, etc.
(Following your lead here.)
9. For flexible IR transmit hardware, the one IR transmitter should be
capable of sending codes to STBs with different protocols or keymaps
(not at the same time of course).
Regards,
Andy
Christoph Bartelmus
on 27 Nov 09 at 10:57, Jon Smirl 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?
> Take advantage of the fact that we don't have a twenty year old legacy
> API already in the kernel. Design an IR API that uses current kernel
> systems. Christoph, ignore the code I wrote and make a design proposal
> that addresses these goals...
>
> 1) Unified input in Linux using evdev. IR is on equal footing with
> mouse and keyboard.
Full support given with LIRC by using uinput.
> 2) plug and play for basic systems - you only need an external app for
> scripting
LIRC is lacking in plug and play support. But it wouldn't be very
difficult to add some that works for all basic systems.
As I'm favouring a solution outside of the kernel, of course I can't offer
you a solution which works without userspace tools.
> 3) No special tools - use mkdir, echo, cat, shell scripts to build
> maps
A user friendly GUI tool to configure the mapping of the remote buttons is
essential for good user experience. I hope noone here considers that users
learn command line or bash to configure their remotes.
> 4) Use of modern Linux features like sysfs, configfs and udev.
LIRC uses sysfs where appropriate. I have no problem using modern
interfaces where it makes sense. But I won't change working and well
tested interfaces just because it's possible to implement the same thing a
different way. The interface is efficient and small. I don't see how it
could gain much by the mentioned featues.
Tell me what exactly you don't like about the LIRC interface and we can
work on it.
> 5) Direct multi-app support - no daemon
lircd is multi-app. I want to be in userspace, so I need a daemon.
> 6) Hide timing data from user as much as possible.
Nobody is manually writing lircd.conf files. Of course you don't want the
user to know anything about the technical details unless you really want
to get your hands dirty.
> What are other goals for this subsystem?
>
> Maybe we decide to take the existing LIRC system as is and not
> integrate it into the input subsystem. But I think there is a window
> here to update the LIRC design to use the latest kernel features.
If it ain't broke, don't fix it.
I'm also not against using the input layer where it makes sense.
For devices that do the decoding in hardware, the only thing that I don't
like about the current kernel implementation is the fact that there are
mapping tables in the kernel source. I'm not aware of any tools that let
you change them without writing some keymaps manually.
I'm also not against in-kernel decoding in general. We already agreed last
year that we can include an interface in lirc_dev that feeds the signal
data to an in-kernel decoder if noone from userspace reads it. That's
close to an one line change in lirc_dev. You won't have to change a single
device driver for this. I think there also was common understanding that
there will be cases where in-kernel decoding will not be possible for
esoteric protocols and that there needs to be an interface to deliver the
raw data to userspace.
My point just is that it took LIRC a very long time until the most common
protocols have been fully supported, with all the toggle bits, toggle
masks, repeat codes, sequences, headers, differing gap values, etc. Or
take a look at crappy hardware like the Igor Cesko's USB IR Receiver. This
device cripples the incoming signal except RC-5 because it has a limited
buffer size. LIRC happily accepts the data because it does not make any
assumptions on the protocol or bit length. With the approach that you
suggested for the in-kernel decoder, this device simply will not work for
anything but RC-5. The devil is in all the details. If we decide to do the
decoding in-kernel, how long do you think this solution will need to
become really stable and mainline? Currently I don't even see any
consensus on the interface yet. But maybe you will prove me wrong and it's
just that easy to get it all working.
I also understand that people want to avoid dependency on external
userspace tools. All I can tell you is that the lirc tools already do
support everything you need for IR control. And as it includes a lot of
drivers that are implemented in userspace already, LIRC will just continue
to do it's work even when there is an alternative in-kernel.
If LIRC is being rejected I don't have a real problem with this either,
but we finally need a decision because for me this is definitely the last
attempt to get this into the kernel.
Christoph
Jon Smirl
Christoph, take what you know from all of the years of working on LIRC
and design the perfect in-kernel system. This is the big chance to
redesign IR support and get rid of any past mistakes. Incorporate any
useful chunks of code and knowledge from the existing LIRC into the
new design. Drop legacy APIs, get rid of daemons, etc. You can do this
redesign in parallel with existing LIRC. Everyone can continue using
the existing code while the new scheme is being built. Think of it as
LIRC 2.0. You can lead this design effort, you're the most experience
developer in the IR area. Take advantage of this window to make a
design that is fully integrated with Linux - put IR on equal footing
with the keyboard and mouse as it should be.
--
Jon Smirl
jons...@gmail.com
Ferenc Wagner
> On Fri, Nov 27, 2009 at 12:29 PM, Christoph Bartelmus <li...@bartelmus.de> wrote:
>
>>> Maybe we decide to take the existing LIRC system as is and not
>>> integrate it into the input subsystem. But I think there is a window
>>> here to update the LIRC design to use the latest kernel features.
>>
>> If it ain't broke, don't fix it. [...]
>>
>> We already agreed last year that we can include an interface in
>> lirc_dev that feeds the signal data to an in-kernel decoder if noone
>> from userspace reads it. [...]
>>
>> I also understand that people want to avoid dependency on external
>> userspace tools. All I can tell you is that the lirc tools already do
>> support everything you need for IR control. And as it includes a lot of
>> drivers that are implemented in userspace already, LIRC will just continue
>> to do it's work even when there is an alternative in-kernel.
>
> Christoph, take what you know from all of the years of working on LIRC
> and design the perfect in-kernel system.
Hi,
I'm reading this thread with great interest. Thank you (plural) for the
very informative conversation, I think I learnt a lot. But now I
somehow lost the point, please correct me if the following is wrong.
It looks like having lirc_dev (or a similar raw interface) is a must.
It could be disguised as an input device, or changed in various ways,
but is it worth the effort? As I understand Christoph, he does not want
to do so, because he finds it wasted work, and also there's already a
*single* user space daemon using it and doing everything users could
want. Except for plug&play.
On the other hand, a one-liner could make in-kernel decoding possible,
so those who haven't got lircd running could have plug&play easily, if
somebody writes the necessary in-kernel decoders to feed the input
subsystem (which lircd also does, through uinput).
But even if you can't find anybody at the moment to write those, this is
still good stuff (I don't know about the code), which is hurt by being
developed out of kernel. Is there any reason to keep this so?
Admittedly, I don't know why /dev/mouse is evil, maybe I'd understand if
somebody pointed me to some reading.
--
Thanks,
Feri.
Jon Smirl
> Jon Smirl <jons...@gmail.com> writes:
>
>> On Fri, Nov 27, 2009 at 12:29 PM, Christoph Bartelmus <li...@bartelmus.de> wrote:
>>
>>>> Maybe we decide to take the existing LIRC system as is and not
>>>> integrate it into the input subsystem. But I think there is a window
>>>> here to update the LIRC design to use the latest kernel features.
>>>
>>>
>>> We already agreed last year that we can include an interface in
>>> lirc_dev that feeds the signal data to an in-kernel decoder if noone
>>>
>>> I also understand that people want to avoid dependency on external
>>> userspace tools. All I can tell you is that the lirc tools already do
>>> support everything you need for IR control. And as it includes a lot of
>>> drivers that are implemented in userspace already, LIRC will just continue
>>> to do it's work even when there is an alternative in-kernel.
>>
>> Christoph, take what you know from all of the years of working on LIRC
>> and design the perfect in-kernel system.
>
> Hi,
>
> very informative conversation, I think I learnt a lot. �ｿｽBut now I
> somehow lost the point, please correct me if the following is wrong.
>
> It looks like having lirc_dev (or a similar raw interface) is a must.
> It could be disguised as an input device, or changed in various ways,
> to do so, because he finds it wasted work, and also there's already a
> *single* user space daemon using it and doing everything users could
The high level summary:
LIRC has developed it's own way of doing things. It has its own device
protocol, user space daemon, tools, etc. No one is denying that all of
that works.
The alternative is to rework IR to use standard kernel interfaces
(evdev, sysfs, configfs), standard user space tools (udev, ls, mkdir,
cat) and make the daemon optional.
Since IR hasn't been added to the kernel yet we are still free to
design the user space API before locking it in stone for the next
twenty years.
This is an architectural debate, not a debate on specific features.
>
> On the other hand, a one-liner could make in-kernel decoding possible,
> so those who haven't got lircd running could have plug&play easily, if
> somebody writes the necessary in-kernel decoders to feed the input
> subsystem (which lircd also does, through uinput).
>
> But even if you can't find anybody at the moment to write those, this is
> still good stuff (I don't know about the code), which is hurt by being
> developed out of kernel. �ｿｽIs there any reason to keep this so?
> Admittedly, I don't know why /dev/mouse is evil, maybe I'd understand if
/dev/mouse is evil because it is possible to read partial mouse
messages. evdev fixes things so that you only get complete messages.
> somebody pointed me to some reading.
> --
> Thanks,
> Feri.
>
--
Jon Smirl
jons...@gmail.com
Stefan Richter
> 3) No special tools - use mkdir, echo, cat, shell scripts to build maps
From the POV of a distributor, there is always a special tool required.
Whether it is implemented in bash, Python, or C doesn't make a
difference to him.
For an enduser whose distributor doesn't package that tool, it also
doesn't matter whether it is bash or Python. (C is awkward because it
needs to be run through gcc first.) A Pyton tool can operate the
existing EVIOCSKEYCODE interface just as well as a C tool.
Your mkdir/ echo/ cat programs would still just this: Programs. Sure,
these programs would be interpreted by an interpreter which is installed
everywhere, and the data they operate on is in a clear text format. The
downside is that these programs do not exist yet.
> 5) Direct multi-app support - no daemon
Think of lircd (when it feeds into uinput) as of a userspace driver
rather than a daemon. The huge benefit of a userspace driver is that it
can load configuration files.
Multi-app support is provided by evdev of course.
> What are other goals for this subsystem?
- Minimal development cost; reduced maintenance cost relative
the to status quo.
- No regressions would be best.
--
Stefan Richter
-=====-==--= =-== ==-==
http://arcgraph.de/sr/
Maxim Levitsky
> Jon Smirl wrote:
> > 3) No special tools - use mkdir, echo, cat, shell scripts to build maps
>
> From the POV of a distributor, there is always a special tool required.
> Whether it is implemented in bash, Python, or C doesn't make a
> difference to him.
>
> For an enduser whose distributor doesn't package that tool, it also
> doesn't matter whether it is bash or Python. (C is awkward because it
> needs to be run through gcc first.) A Pyton tool can operate the
> existing EVIOCSKEYCODE interface just as well as a C tool.
>
> Your mkdir/ echo/ cat programs would still just this: Programs. Sure,
> these programs would be interpreted by an interpreter which is installed
> everywhere, and the data they operate on is in a clear text format. The
> downside is that these programs do not exist yet.
>
> > 5) Direct multi-app support - no daemon
>
> Think of lircd (when it feeds into uinput) as of a userspace driver
> rather than a daemon. The huge benefit of a userspace driver is that it
> can load configuration files.
kernel.
Many drivers are pure userspace and live in the lirc daemon itself.
These drivers ether will have to be reimplemented in kernel (huge job)
Or we will have a lot of duplication, because same remote can be used
with kernel or userspace drivers.
Look at daemons subdirectory of lircd to get the idea of how many such
drivers exist.
Btw, for _some_ user space drivers its not possible to re implement them
in kernel, like driver that reads input from a sound card, which I can
say is nice very cheap way to have a receiver.
I want to repeat the correct way of doing things:
1 - all drivers that do all processing in hardware, will use input
system.
2 - all drivers that decode protocol will use ether lirc, to keep
configuration in one place.
3 - all drivers that send pulse/space will use lirc.
lirc will process the data, convert it to input events and feed them
back to kernel.
Please note, and note again.
We aren't taking about two interfaces for userspace!
Everybody agree that userspace programs will only recieve input events.
The point is that we give an exception for one program that yes is just
a userspace driver to recieve the raw data, process it, and feed it
back.
Also same program (lircd) could receive data from other sources, and
convert that to input events.
Whats wrong with that?
If we add in-kernel decoding, we still will end up with two different
decoding, one in kernel and one in lirc.
Could we finally end this discussion and move forward?
Best regards,
Maxim Levitsky
Dmitry Torokhov
For me the main evil of /dev/mouse (and other multuiplexing interfaces)
is that it is impossible to remove one of the streams from the
multiplexed stream without affecting other users. And so are born
various "grab" schemes where we declare one application _the
application_ and let it "grab" the device.. which breaks when there are
other applications also interested in the same data stream.
--
Dmitry
Simon Kenyon
> A user friendly GUI tool to configure the mapping of the remote
buttons is
> essential for good user experience. I hope noone here considers that
users
> learn command line or bash to configure their remotes.
oh please no
the major, major problem with bluetooth is that there is *only* a gui
the core system should use the command line and then a gui (or guis) can
follow
> Nobody is manually writing lircd.conf files. Of course you don't want
the
> user to know anything about the technical details unless you really
want
> to get your hands dirty.
speak for yourself
> If it ain't broke, don't fix it.
i have been hacking lirc for *so many years* because i needed two
separate serial inputs. so that is most assuredly broken
Mauro Carvalho Chehab
Christoph Bartelmus wrote:
>> Maybe we decide to take the existing LIRC system as is and not
>> integrate it into the input subsystem. But I think there is a window
>> here to update the LIRC design to use the latest kernel features.
>
> If it ain't broke, don't fix it.
I don't know what's up on lirc development, but in the case of the media drivers,
the situation we have currently is different than what we had five years ago. In
the past, all drivers were developed by a someone without any official help from
the hardware developer. On several cases, it were developed _despite_ vendors
efforts to hide technical info. Basically, vendors weren't interested
on officially support Linux.
Now, the situation has changed. We have several vendors providing patches
and drivers to the community and we have incoming vendors joining the efforts
almost every month. They are not only providing basic streaming capabilities
but also providing us patches for the shipped IR's.
If the developers community is changed, it is natural that the development
model needs improvements to better handle the new model, as they're bringing
new demands and asking for API improvements.
One of the effects is that we're actively working very hard to improve the core
of the subsystem, in order to provide more flexibility on the subsystem and
to make easier to receive patch contributions.
So, even not being broken, the subsystem internal media API's changed
a lot during the last years, and there are still several new changes
on our TODO list.
So, I'd say that if we can do it better, then let's do it.
> I'm also not against using the input layer where it makes sense.
>
> For devices that do the decoding in hardware, the only thing that I don't
> like about the current kernel implementation is the fact that there are
> mapping tables in the kernel source. I'm not aware of any tools that let
> you change them without writing some keymaps manually.
When the keymap tool I pointed is built, The Makefile automatically parses all
kernel source files with IR keymaps and produce a directory with all those
keymaps (currently, it is producing 89 keymap tables).
After we have some sort of tool that automatically loads the keymaps when
a new device is added by udev, we can deprecate the in-kernel keymaps and use
those files as a basis for such tool.
Still, I prefer first to migrate all drivers to use the full scancode and
re-generate the keymaps before such step.
> I'm also not against in-kernel decoding in general. We already agreed last
> year that we can include an interface in lirc_dev that feeds the signal
> data to an in-kernel decoder if noone from userspace reads it. That's
> close to an one line change in lirc_dev. You won't have to change a single
> device driver for this. I think there also was common understanding that
> there will be cases where in-kernel decoding will not be possible for
> esoteric protocols and that there needs to be an interface to deliver the
> raw data to userspace.
>
> My point just is that it took LIRC a very long time until the most common
> protocols have been fully supported, with all the toggle bits, toggle
> masks, repeat codes, sequences, headers, differing gap values, etc.
It also took a very long time to add support at the existing in-kernel drivers
to allow them to support the shipped IR and the hardware IR decoding
capabilities, in order to provide consistent interfaces that work out-of-the-box.
Any API decision we take, it should be applied to all IR drivers: the
current in-kernel drivers and the new lirc drivers should both be
compliant with the API's. So, we are all at the same boat.
As you probably know, on almost all multimedia drivers, the same driver needs
to support more than one way to receive IR. There are even some cases where
the same driver has different methods to talk with the same IR, due to
different design decisions that were taken from the same manufacturer on
different boards or board revisions.
For example, there are several cases where the same IR is shipped with cards
that only provides raw pulse/space interfaces and with devices with
hardware decoding. Also the same IR is sometimes used by different vendors.
It happens that the same driver needs different ways to talk with the same IR.
So, while a raw interface can be provided for those devices that have
raw IR reception to work with lirc, it doesn't make sense of removing
the existing event interface for the devices that requires to use the already
existing in-kernel decoders. We shouldn't impose a penalty to the users just
because the vendor decided to save a few cents and not adding a hardware decoder.
Yet, I understand that having a raw interface for those devices that don't
have hardware IR decoding capabilities is interesting for lirc, as it can
use different algorithms to support unusual devices.
> Or take a look at crappy hardware like the Igor Cesko's USB IR Receiver. This
> device cripples the incoming signal except RC-5 because it has a limited
> buffer size. LIRC happily accepts the data because it does not make any
> assumptions on the protocol or bit length.
For sure there will be cases where only with lirc you'll be able to get
an event. I'm not saying that we need to move the entire lirc drivers into
the kernel. However, in the cases where adding a new kernel driver is
the better approach, the kernel driver should directly offer an evdev interface,
to allow a wider usage of the IR. An IR should behave, by default, just like
a keyboard or a mouse: once the hardware is plugged, it should produce keystrokes.
Also, the solution of a kernel driver that sends a raw event to userspace,
proccess there and return back to the kernel shouldn't be the default, since
it will add more delay than directly doing whatever is needed in kernel and
directly output the keystroke.
> With the approach that you
> suggested for the in-kernel decoder, this device simply will not work for
> anything but RC-5. The devil is in all the details.
I haven't seen such limitations on his proposal. We currently have in-kernel
decoders for NEC, pulse-distance, RC4 protocols, and some variants. If non-RC5
decoders are missing, we need for sure to add them.
> If we decide to do the
> decoding in-kernel, how long do you think this solution will need to
> become really stable and mainline? Currently I don't even see any
> consensus on the interface yet. But maybe you will prove me wrong and it's
> just that easy to get it all working.
The timeframe to go to mainline will basically depend on taking a decision about the
API and on people having time to work on it.
Providing that we agree on what we'll do, I don't see why not
adding it on staging for 2.6.33 and targeting to have
everything done for 2.6.34 or 2.6.35.
> I also understand that people want to avoid dependency on external
> userspace tools. All I can tell you is that the lirc tools already do
> support everything you need for IR control. And as it includes a lot of
> drivers that are implemented in userspace already, LIRC will just continue
> to do it's work even when there is an alternative in-kernel.
The point is that for simple usage, like an user plugging his new USB stick
he just bought, he should be able to use the shipped IR without needing to
configure anything or manually calling any daemon. This currently works
with the existing drivers and it is a feature that needs to be kept.
Of course lirc has a number of features that improves a lot the users experience.
Also, as you reminded, there are some cases where the user wants to do something
that requires a setup, like using a non-standard IR, or wants to use some user-made
hardware to receive IR.
> If LIRC is being rejected I don't have a real problem with this either,
> but we finally need a decision because for me this is definitely the last
> attempt to get this into the kernel.
Nobody is rejecting it, but we need to carefully discuss the API's that
will be available for IR's.
At the kernel development model, API's need to be stable for a very long time. So,
it is better to take some time discussing it than to suffer for a long time
trying to solve a bad decision.
Just as an example, V4L1 API went on kernel in 1999, and the first V4L2 API drafts
are back from 2002. The new API corrects several serious design problems on the
original V4L1 API. Still today, we're converting drivers to the new API
and loosing our time fixing bugs and porting applications to use the new model.
Maybe if people had better understanding about the needs
and could had V4L2 API done before adding the first drivers, we would
had saved a huge amount of efforts trying to fix it.
The same history also happened with /dev/mouse, with OSS/ALSA, ...
As we now have a good understanding about the IR input needs, let's
focus on producing an API that will last there for a long time, please.
Cheers,
Mauro.
Krzysztof Halasa
> If we add in-kernel decoding, we still will end up with two different
> decoding, one in kernel and one in lirc.
And that's good. Especially for a popular and simple protocol such as
RC5.
Actually, it's not about adding the decoder. It's about fixing it.
I can fix it.
--
Krzysztof Halasa
Maxim Levitsky
> Maxim Levitsky <maximl...@gmail.com> writes:
>
> > If we add in-kernel decoding, we still will end up with two different
> > decoding, one in kernel and one in lirc.
>
> And that's good. Especially for a popular and simple protocol such as
> RC5.
> Actually, it's not about adding the decoder. It's about fixing it.
> I can fix it.
This is nonsense.
Krzysztof Halasa
>> And that's good. Especially for a popular and simple protocol such as
>> RC5.
>> Actually, it's not about adding the decoder. It's about fixing it.
>> I can fix it.
>
> This is nonsense.
You forgot to say why do you think so.
--
Krzysztof Halasa
Maxim Levitsky
> Maxim Levitsky <maximl...@gmail.com> writes:
>
> >> And that's good. Especially for a popular and simple protocol such as
> >> RC5.
> >> Actually, it's not about adding the decoder. It's about fixing it.
> >> I can fix it.
> >
> > This is nonsense.
>
> You forgot to say why do you think so.
Because frankly, I am sick of this discussion.
Generic decoder that lirc has is actually much better and more tolerant
that protocol specific decoders that you propose,
You claim you 'fix' the decoder, right?
But what about all these lirc userspace drivers?
How they are supposed to use that 'fixed' decoder.
Krzysztof Halasa
> Generic decoder that lirc has is actually much better and more tolerant
> that protocol specific decoders that you propose,
Actually, it is not the case. Why do you think it's better (let alone
"much better")? Have you at least seen my RC5 decoder?
> You claim you 'fix' the decoder, right?
Sure.
> But what about all these lirc userspace drivers?
Nothing. They are not relevant and obviously have to use lircd.
If you can have userspace driver, you can have lircd as well.
> How they are supposed to use that 'fixed' decoder.
They are not.
Is it a problem for you?
How is your keyboard supposed to use scanner driver?
--
Krzysztof Halasa
Maxim Levitsky
> Maxim Levitsky <maximl...@gmail.com> writes:
>
> > Generic decoder that lirc has is actually much better and more tolerant
> > that protocol specific decoders that you propose,
>
> Actually, it is not the case. Why do you think it's better (let alone
> "much better")? Have you at least seen my RC5 decoder?
as long as pulses vary in size it can distinguish between keys, and that
is enough.
I didn't use your decoder, so in that particular case I don't know.
>
> > You claim you 'fix' the decoder, right?
>
> Sure.
Unless you put it againt an inaccurate decoder....
Ask the lirc developers.
>
> > But what about all these lirc userspace drivers?
>
> Nothing. They are not relevant and obviously have to use lircd.
> If you can have userspace driver, you can have lircd as well.
>
> > How they are supposed to use that 'fixed' decoder.
>
> They are not.
>
> Is it a problem for you?
> How is your keyboard supposed to use scanner driver?
Another piece of off-topic nonsense.
I have a VCR remote, ok?
I have a pulse/space decoder in my notebook, I have created a config
file for that, and I did a lot of customizations, because this remote
isn't supposed to be used with PC.
Now, I also have a desktop.
I don't have a receiver there, but someday I arrange some sort of it.
I have an IR dongle in the closed, its raw IR diode.
Probably with few components I could connect it to soundcard (and I have
3 independent inputs, of which only one is used)
And then I will use alsa input driver.
Now I had ended up with 2 different configurations, one for the kernel,
another for the lirc.
Great, isn't it?
The point is again, I *emphasize* that as long as lirc is used to decode
all but ready to use scancodes, everything is kept in one place.
Both decode algorithms and configuration.
For ready to use scancode, a hardcoded table can be used in kernel to
translate to input events.
How hard to understand that?
Also, I repeat again, that this discussion *IS NOT* about userspace api,
its about who decodes the input, kernel or lirc.
Raw access to timing will be aviable this way or another, ether as
primary way of decoding for lirc, or as a debug measure.
Regards,
Maxim Levitsky
Christoph Bartelmus
on 28 Nov 09 at 16:44, Krzysztof Halasa wrote:
> Maxim Levitsky <maximl...@gmail.com> writes:
>> Generic decoder that lirc has is actually much better and more tolerant
>> that protocol specific decoders that you propose,
> Actually, it is not the case. Why do you think it's better (let alone
> "much better")? Have you at least seen my RC5 decoder?
Nobody here doubts that you can implement a working RC-5 decoder. It's
really easy. I'll give you an example why Maxim thinks that the generic
LIRC approach has advantages:
Look at the Streamzap remote (I think Jarod submitted the lirc_streamzap
driver in his patchset):
http://lirc.sourceforge.net/remotes/streamzap/PC_Remote
This remote uses RC-5. But some of the developers must have thought that
it may be a smart idea to use 14 bits instead the standard 13 bits for
this remote. In LIRC you won't care, because this is configurable and
irrecord will figure it out automatically for you. In the proposed kernel
decoders I have seen until now, you will have to treat this case specially
in the decoder because you expect 13 bits for RC-5, not 14.
Well, it can be done. But you'll have to add another IR protocol define
for RC-5_14, which will become very ugly with many non-standard protocol
variations.
@Maxim: I think Mauro is right. We need to find an approach that makes
everybody happy. We should take the time now to discuss all the
possibilities and choose the best solution. LIRC has lived so long outside
the kernel, that we can wait another couple of weeks/months until we
agreed on something which will be a stable API hopefully for many years to
come.
Christoph
Krzysztof Halasa
>> Actually, it is not the case. Why do you think it's better (let alone
>> "much better")? Have you at least seen my RC5 decoder?
> Because userspace decoder is general, it doesn't depend on exact timing,
> as long as pulses vary in size it can distinguish between keys, and that
> is enough.
> I didn't use your decoder, so in that particular case I don't know.
I thought so.
FYI: a sane RC5 decoder doesn't depend on exact timing. Even seen
a multi-function remote can control many different devices like TV,
VCR, DVD and so on? From different manufacturers etc.
> Unless you put it againt an inaccurate decoder....
> Ask the lirc developers.
Not sure what do you mean.
> I have a VCR remote, ok?
> I have a pulse/space decoder in my notebook, I have created a config
> file for that, and I did a lot of customizations, because this remote
> isn't supposed to be used with PC.
There is no such thing as "being supposed to be used with PC".
A space/mark receiver can receive data from any remote.
> Now, I also have a desktop.
> I don't have a receiver there, but someday I arrange some sort of it.
> I have an IR dongle in the closed, its raw IR diode.
> Probably with few components I could connect it to soundcard (and I have
> 3 independent inputs, of which only one is used)
> And then I will use alsa input driver.
>
> Now I had ended up with 2 different configurations, one for the kernel,
> another for the lirc.
> Great, isn't it?
If you want such setup - why not?
If you don't - you can use lirc in both cases.
> The point is again, I *emphasize* that as long as lirc is used to decode
> all but ready to use scancodes, everything is kept in one place.
> Both decode algorithms and configuration.
Then keep it that way and let others use what they think is best for
them.
Now how hard is it to understand that?
> Also, I repeat again, that this discussion *IS NOT* about userspace api,
> its about who decodes the input, kernel or lirc.
That could be the case if you were limited to "or". But we can do both.
--
Krzysztof Halasa
Jon Smirl
<maximl...@gmail.com> wrote:
> On Sat, 2009-11-28 at 16:25 +0100, Krzysztof Halasa wrote:
>> Maxim Levitsky <maximl...@gmail.com> writes:
>>
>> >> And that's good. Especially for a popular and simple protocol such as
>> >> RC5.
>> >> Actually, it's not about adding the decoder. It's about fixing it.
>> >> I can fix it.
>> >
>> > This is nonsense.
>>
>> You forgot to say why do you think so.
>
> Because frankly, I am sick of this discussion.
> Generic decoder that lirc has is actually much better and more tolerant
> that protocol specific decoders that you propose,
Porting the decoder engine from lirc into the kernel is also a possibility.
I'm asking to have an architecture design discussion, not to pick one
of the various implementations. This is something that we have to live
with for twenty years and it is a giant pain to change if we get wrong
initially.
> You claim you 'fix' the decoder, right?
> But what about all these lirc userspace drivers?
> How they are supposed to use that 'fixed' decoder.
Some of that user space hardware belongs in the trash can and will
never work reliably in a modern system. For example - sitting in a
tight user space loop reading the DTS bit from a serial port or
parallel port and then using the system clock to derive IR timings.
That process is going to be inaccurate or it is going to make video
frames drop. Big banging from user space is completely unreliable.
If you really want to use your microphone input as a DAC channel, run
a little app that reads the ALSA input and converts it to a timing
stream and then inject this data into the kernel input system using
uevent.
Both of these are hobbyist class solutions. They are extremely cheap
but they are unreliable and create large CPU loads. But some people
want to use a $300 CPU to eliminate $2 worth of IR hardware. This type
of hardware will continue to work via event injection. But neither of
these solutions belong in the kernel.
What are other examples of user space IR drivers?
--
Jon Smirl
jons...@gmail.com
Jon Smirl
> @Maxim: I think Mauro is right. We need to find an approach that makes
> everybody happy. We should take the time now to discuss all the
> possibilities and choose the best solution. LIRC has lived so long outside
> the kernel, that we can wait another couple of weeks/months until we
> agreed on something which will be a stable API hopefully for many years to
> come.
Please do this. That's why I started this thread off with goals for
the implementation. After we settle on a set of goals we can move on
to how to implement those goals. The end result is almost certainly
going to combine aspects from all of the various proposals and the
LIRC code base is likely to be the largest contributor.
There are two very basic things that we need to reach consensus on first.
1) Unification with mouse/keyboard in evdev - put IR on equal footing.
2) Specific tools (xmodmap, setkeycodes, etc or the LIRC ones) or
generic tools (ls, mkdir, echo) for configuration
Once consensus is reached in those two areas everything else should be
much easier.
--
Jon Smirl
jons...@gmail.com
Krzysztof Halasa
> Nobody here doubts that you can implement a working RC-5 decoder. It's
> really easy. I'll give you an example why Maxim thinks that the generic
> LIRC approach has advantages:
But surely not when compared to an in-kernel decoder _and_ the one in
lircd? :-)
> Look at the Streamzap remote (I think Jarod submitted the lirc_streamzap
> driver in his patchset):
> http://lirc.sourceforge.net/remotes/streamzap/PC_Remote
>
> This remote uses RC-5. But some of the developers must have thought that
> it may be a smart idea to use 14 bits instead the standard 13 bits for
> this remote. In LIRC you won't care, because this is configurable and
> irrecord will figure it out automatically for you. In the proposed kernel
> decoders I have seen until now, you will have to treat this case specially
> in the decoder because you expect 13 bits for RC-5, not 14.
Well, the 14-bit RC5 is de-facto standard for some time now. One of the
start bits, inverted, now functions as the MSB of the command code.
13-bit receiver implementations (at least these aimed at "foreign"
remotes) are obsolete.
> Well, it can be done. But you'll have to add another IR protocol define
> for RC-5_14, which will become very ugly with many non-standard protocol
> variations.
No, the 14-bit version is designed to be backward compatible.
--
Krzysztof Halasa
Krzysztof Halasa
> There are two very basic things that we need to reach consensus on first.
>
> 1) Unification with mouse/keyboard in evdev - put IR on equal footing.
> 2) Specific tools (xmodmap, setkeycodes, etc or the LIRC ones) or
> generic tools (ls, mkdir, echo) for configuration
I think we can do this gradually:
1. Merging the lirc drivers. The only stable thing needed is lirc
interface.
2. Changing IR input layer interface ("media" drivers and adding to lirc
drivers).
--
Krzysztof Halasa
Jon Smirl
> Jon Smirl <jons...@gmail.com> writes:
>
>> There are two very basic things that we need to reach consensus on first.
>>
>> 1) Unification with mouse/keyboard in evdev - put IR on equal footing.
>> 2) Specific tools (xmodmap, setkeycodes, etc or the LIRC ones) or
>> generic tools (ls, mkdir, echo) for configuration
>
> I think we can do this gradually:
> 1. Merging the lirc drivers. The only stable thing needed is lirc
> � interface.
Doing that locks in a user space API that needs to be supported
forever. We need to think this API through before locking it in.
> 2. Changing IR input layer interface ("media" drivers and adding to lirc
> � drivers).
> --
> Krzysztof Halasa
>
--
Jon Smirl
jons...@gmail.com
Krzysztof Halasa
>> 1. Merging the lirc drivers. The only stable thing needed is lirc
>> interface.
>
> Doing that locks in a user space API that needs to be supported
> forever. We need to think this API through before locking it in.
Sure, that's why I wrote about the need for it to be "stable".
--
Krzysztof Halasa
Stefan Richter
> There are two very basic things that we need to reach consensus on first.
>
> 1) Unification with mouse/keyboard in evdev - put IR on equal footing.
> 2) Specific tools (xmodmap, setkeycodes, etc or the LIRC ones) or
> generic tools (ls, mkdir, echo) for configuration
About 2: If at all, there only needs to be a decision about pulse/space
to scancode converter configuration. In contrast, scancode to keycode
converter configuration is already solved; the interface is
EVIOCSKEYCODE. If you find the EVIOCSKEYCODE interface lacking, extend
it or submit an alternative --- but this does not affect LIRC and
whether to merge it in any way.
PS: Drop your "specific vs. generic tools" terminology already. Your
configfs based proposal requires "specific" tools as well, it's just
that they can be implemented in bash, among else.
--
Stefan Richter
-=====-==--= =-== ===--
http://arcgraph.de/sr/
Maxim Levitsky
many libusb based drivers?
Regards,
Maxim Levitsky
Jon Smirl
> On Sat, 2009-11-28 at 11:45 -0500, Jon Smirl wrote:
>> What are other examples of user space IR drivers?
>>
>
> many libusb based drivers?
If these drivers are for specific USB devices it is straight forward
to turn them into kernel based drivers. If we are going for plug and
play this needs to happen. All USB device drivers can be implemented
in user space, but that doesn't mean you want to do that. Putting
device drivers in the kernel subjects them to code inspection, they
get shipped everywhere, they autoload when the device is inserted,
they participate in suspend/resume, etc.
If these are generic USB serial devices being used to implement IR
that's the hobbyist model and the driver should stay in user space and
use event injection.
If a ft232 has been used to build a USB IR receiver you should program
a specific USB ID into it rather than leaving the generic one in. FTDI
will assign you a specific USB ID out of their ID space for free, you
don't need to pay to get one from the USB forum. Once you put a
specific ID into the ft232 it will trigger the load of the correct
in-kernel driver.
>
> Regards,
> Maxim Levitsky
>
>
--
Jon Smirl
jons...@gmail.com
Jon Smirl
<ste...@s5r6.in-berlin.de> wrote:
> Jon Smirl wrote:
>> There are two very basic things that we need to reach consensus on first.
>>
>> 1) Unification with mouse/keyboard in evdev - put IR on equal footing.
>> 2) Specific tools (xmodmap, setkeycodes, etc or the LIRC ones) or
>> generic tools (ls, mkdir, echo) for configuration
>
> About 2: �If at all, there only needs to be a decision about pulse/space
> to scancode converter configuration. �In contrast, scancode to keycode
> converter configuration is already solved; the interface is
> EVIOCSKEYCODE. �If you find the EVIOCSKEYCODE interface lacking, extend
> it or submit an alternative --- but this does not affect LIRC and
> whether to merge it in any way.
EVIOCSKEYCODE is lacking, first parameter is an INT. Some decoded IR
codes are over 32b. Christoph posted an example that needs 128b. This
is a problem with ioctls, they change size depending on platform and
endianess.
Also, how do you create the devices for each remote? You would need to
create these devices before being able to do EVIOCSKEYCODE to them.
>
> PS: �Drop your "specific vs. generic tools" terminology already. �Your
> configfs based proposal requires "specific" tools as well, it's just
> that they can be implemented in bash, among else.
The shell commands are the most generic tools in Unix. udev already
knows how to run shell scripts.
But there is no technical reason why setkeycodes, getkeycodes,
showkey, loadkeys, xmodmap, and dump-keys can't be modified to support
IR. I already have to have the man page on the screen when using these
commands so adding a bunch more parameters won't hurt.
> --
> Stefan Richter
> -=====-==--= =-== ===--
> http://arcgraph.de/sr/
>
--
Jon Smirl
jons...@gmail.com
Maxim Levitsky
> On Sat, Nov 28, 2009 at 1:45 PM, Maxim Levitsky <maximl...@gmail.com> wrote:
> > On Sat, 2009-11-28 at 11:45 -0500, Jon Smirl wrote:
> >> What are other examples of user space IR drivers?
> >>
> >
> > many libusb based drivers?
>
> If these drivers are for specific USB devices it is straight forward
> to turn them into kernel based drivers. If we are going for plug and
> play this needs to happen. All USB device drivers can be implemented
> in user space, but that doesn't mean you want to do that. Putting
> device drivers in the kernel subjects them to code inspection, they
> get shipped everywhere, they autoload when the device is inserted,
> they participate in suspend/resume, etc.
>
> If these are generic USB serial devices being used to implement IR
> that's the hobbyist model and the driver should stay in user space and
> use event injection.
>
> If a ft232 has been used to build a USB IR receiver you should program
> a specific USB ID into it rather than leaving the generic one in. FTDI
> will assign you a specific USB ID out of their ID space for free, you
> don't need to pay to get one from the USB forum. Once you put a
> specific ID into the ft232 it will trigger the load of the correct
> in-kernel driver.
If we could put *all* lirc drivers in the kernel and put the generic
decoding algorithm, then it might be begin to look a bit more sane.
And write tool to upload the existing lirc config files to kernel.
This would essentially we same as porting the lirc to the kernel.
I don't see much gains of this, and this way or another, alsa input
won't be possible.
Christoph Bartelmus, Jarod Wilson, what do you think?
Regards,
Maxim Levitsky
Jon Smirl
>> to turn them into kernel based drivers. If we are going for plug and
>> play this needs to happen. All USB device drivers can be implemented
>> in user space, but that doesn't mean you want to do that. Putting
>> device drivers in the kernel subjects them to code inspection, they
>> get shipped everywhere, they autoload when the device is inserted,
>> they participate in suspend/resume, etc.
>
> crash your machine), they /can/ be and are shipped everywhere, they /do/
> auto-load when the device is inserted. �And if there should be an issue
> with power management (is there any?), then improve the ABI and libusb
> can surely be improved. �I don't see why a device with a userspace
> driver cannot be included in power management.
If you want a micro-kernel there are plenty to pick from. Linux has
chosen not to be a micro-kernel. The Linux model is device drivers in
the kernel.
Stefan Richter
> If these drivers are for specific USB devices it is straight forward
> to turn them into kernel based drivers. If we are going for plug and
> play this needs to happen. All USB device drivers can be implemented
> in user space, but that doesn't mean you want to do that. Putting
> device drivers in the kernel subjects them to code inspection, they
> get shipped everywhere, they autoload when the device is inserted,
> they participate in suspend/resume, etc.
Huh? Userspace implementations /can/ be code-reviewed (but they can't
crash your machine), they /can/ be and are shipped everywhere, they /do/
auto-load when the device is inserted. And if there should be an issue
with power management (is there any?), then improve the ABI and libusb
can surely be improved. I don't see why a device with a userspace
driver cannot be included in power management.
--
Stefan Richter
-=====-==--= =-== ===--
http://arcgraph.de/sr/
Stefan Richter
> On Sat, Nov 28, 2009 at 1:17 PM, Stefan Richter
> <ste...@s5r6.in-berlin.de> wrote:
>> Jon Smirl wrote:
>>> There are two very basic things that we need to reach consensus on first.
>>>
>>> 1) Unification with mouse/keyboard in evdev - put IR on equal footing.
>>> 2) Specific tools (xmodmap, setkeycodes, etc or the LIRC ones) or
>>> generic tools (ls, mkdir, echo) for configuration
>> About 2: If at all, there only needs to be a decision about pulse/space
>> to scancode converter configuration. In contrast, scancode to keycode
>> converter configuration is already solved; the interface is
>> EVIOCSKEYCODE. If you find the EVIOCSKEYCODE interface lacking, extend
>> it or submit an alternative --- but this does not affect LIRC and
>> whether to merge it in any way.
>
> EVIOCSKEYCODE is lacking, first parameter is an INT. Some decoded IR
> codes are over 32b. Christoph posted an example that needs 128b. This
> is a problem with ioctls, they change size depending on platform and
> endianess.
No, they do not "change size depending on platform and endianess" if
basic rules are observed. Defining compatible ioctls is not rocket
science. Sure, "int" should not be used in ioctl arguments or other
binary interfaces.
(I never said EVIOCSKEYCODE was not lacking, I only said it exists
already. When you talk about better scancode-to-keycode converter
configuration, then you are talking about EVIOCSKEYCODE, not about LIRC
or a hypothetic replacement of LIRC. Ergo, the decision about whether
to merge LIRC or not is not blocked by this configuration interface issue.)
> Also, how do you create the devices for each remote? You would need to
> create these devices before being able to do EVIOCSKEYCODE to them.
The input subsystem creates devices on behalf of input drivers. (Kernel
drivers, that is. Userspace drivers are per se not affected.)
>> PS: Drop your "specific vs. generic tools" terminology already. Your
>> configfs based proposal requires "specific" tools as well, it's just
>> that they can be implemented in bash, among else.
>
> The shell commands are the most generic tools in Unix.
The shell scripts are still special-purpose programs.
> udev already knows how to run shell scripts.
[...]
Udev can run any kind of program, compiled or interpreted.
--
Stefan Richter
-=====-==--= =-== ===--
http://arcgraph.de/sr/
--
Stefan Richter
> On Sat, Nov 28, 2009 at 2:30 PM, Stefan Richter
> <ste...@s5r6.in-berlin.de> wrote:
>> Jon Smirl wrote:
>>> If these drivers are for specific USB devices it is straight forward
>>> to turn them into kernel based drivers. If we are going for plug and
>>> play this needs to happen. All USB device drivers can be implemented
>>> in user space, but that doesn't mean you want to do that. Putting
>>> device drivers in the kernel subjects them to code inspection, they
>>> get shipped everywhere, they autoload when the device is inserted,
>>> they participate in suspend/resume, etc.
>> Huh? Userspace implementations /can/ be code-reviewed (but they can't
>> crash your machine), they /can/ be and are shipped everywhere, they /do/
>> auto-load when the device is inserted. And if there should be an issue
>> with power management (is there any?), then improve the ABI and libusb
>> can surely be improved. I don't see why a device with a userspace
>> driver cannot be included in power management.
>
> If you want a micro-kernel there are plenty to pick from. Linux has
> chosen not to be a micro-kernel. The Linux model is device drivers in
> the kernel.
Total nonsense. Neither am I arguing for a micro-kernel, nor are
userspace drivers alien to Linux. Not at all.
--
Stefan Richter
-=====-==--= =-== ===--
http://arcgraph.de/sr/
Krzysztof Halasa
> EVIOCSKEYCODE is lacking, first parameter is an INT. Some decoded IR
> codes are over 32b. Christoph posted an example that needs 128b.
This only means that the existing interface is limited.
> This
> is a problem with ioctls, they change size depending on platform and
> endianess.
But not this: you can use fixed-width u16, u32, u64 and e.g. u8[x].
I don't know an arch which changes int sizes depending on endianness,
is there any?
32/64 binary compatibility needs some minimal effort.
--
Krzysztof Halasa
Jon Smirl
<ste...@s5r6.in-berlin.de> wrote:
> Jon Smirl wrote:
>> Also, how do you create the devices for each remote? You would need to
>> create these devices before being able to do EVIOCSKEYCODE to them.
>
> The input subsystem creates devices on behalf of input drivers. �(Kernel
> drivers, that is. �Userspace drivers are per se not affected.)
We have one IR receiver device and multiple remotes. How does the
input system know how many devices to create corresponding to how many
remotes you have? There is no current mechanism to do that. You need
an input device for each remote so that you can do the EVIOCSKEYCODE
against it. Some type of "create subdevice" IOCTL will need to be
built.
I handled that in configds like this:
/configfs - mount the basic configfs
/configfs/remotes (created by loading IR support)
mkdir /configfs/remotes/remote_A - this causes the input subdevice to
be created, the name of it appears in the created directory.
mkdir /configfs/remotes/remote_A/... - now build the mapping entires.
This "create subdevice" IOCTL will need to take a name so that it can
be identified. You will probably another IOCTL to enumerate which
subdevices belong to the root device, etc...
Keyboards don't have subdevices. There is a 1:1 mapping between the
keyboard and the device driver.
--
Jon Smirl
jons...@gmail.com
Jon Smirl
> Jon Smirl <jons...@gmail.com> writes:
>
>> EVIOCSKEYCODE is lacking, first parameter is an INT. Some decoded IR
>> codes are over 32b. Christoph posted an example that needs 128b.
>
> This only means that the existing interface is limited.
>
>> This
>> is a problem with ioctls, they change size depending on platform and
>> endianess.
>
> But not this: you can use fixed-width u16, u32, u64 and e.g. u8[x].
> I don't know an arch which changes int sizes depending on endianness,
> is there any?
Endianess comes into play when send/receiving multibyte integers on
platforms with different endianess. That where the hton() stuff comes
from. IOCTLs obviously work, you just have to allow for all of this
stuff when writing them.
http://linux.die.net/man/3/htonl
> 32/64 binary compatibility needs some minimal effort.
> --
> Krzysztof Halasa
>
--
Jon Smirl
jons...@gmail.com
Krzysztof Halasa
> We have one IR receiver device and multiple remotes. How does the
> input system know how many devices to create corresponding to how many
> remotes you have? There is no current mechanism to do that. You need
> an input device for each remote so that you can do the EVIOCSKEYCODE
> against it. Some type of "create subdevice" IOCTL will need to be
> built.
Thinking about it, I'm not sure. Why do we want multiple remote devices?
(not multiple remotes, that's clear).
--
Krzysztof Halasa
Krzysztof Halasa
> Endianess comes into play when send/receiving multibyte integers on
> platforms with different endianess.
It's the case when you're sending this data to a machine with
a different endianness. For example, in a network or to another CPU in
e.g. add-on card.
Ioctls are not affected by this, since both ends are the same.
Obviously you can be affected if you try to access data as integers in
one point and as arrays of bytes in the other, but it has nothing to do
with ioctls.
--
Krzysztof Halasa
Stefan Richter
> Jon Smirl wrote:
>> We have one IR receiver device and multiple remotes. How does the
>> input system know how many devices to create corresponding to how many
>> remotes you have?
>
> necessarily need to generate different scancodes, don't they? Otherwise
> the input driver wouldn't be able to route their events to the
> respective subdevice. But if they do generate different scancodes,
> there is no need to create subdevices just for EVIOCSKEYCODE's sake. (It
> might still be desirable to have subdevices for other reasons perhaps.)
PS, forgot to add: If there is a real need to initiate device creation
from userspace, then ioctl is not the way to go.
--
Stefan Richter
-=====-==--= =-== ===--
http://arcgraph.de/sr/
Stefan Richter
> On Sat, Nov 28, 2009 at 2:45 PM, Stefan Richter
> <ste...@s5r6.in-berlin.de> wrote:
>> Jon Smirl wrote:
>>> Also, how do you create the devices for each remote? You would need to
>>> create these devices before being able to do EVIOCSKEYCODE to them.
>> The input subsystem creates devices on behalf of input drivers. (Kernel
>> drivers, that is. Userspace drivers are per se not affected.)
>
> We have one IR receiver device and multiple remotes. How does the
> input system know how many devices to create corresponding to how many
> remotes you have?
If several remotes are to be used on the same receiver, then they
necessarily need to generate different scancodes, don't they? Otherwise
the input driver wouldn't be able to route their events to the
respective subdevice. But if they do generate different scancodes,
there is no need to create subdevices just for EVIOCSKEYCODE's sake. (It
might still be desirable to have subdevices for other reasons perhaps.)
--
Stefan Richter
-=====-==--= =-== ===--
http://arcgraph.de/sr/
Jon Smirl
<ste...@s5r6.in-berlin.de> wrote:
> Jon Smirl wrote:
>> On Sat, Nov 28, 2009 at 2:45 PM, Stefan Richter
>> <ste...@s5r6.in-berlin.de> wrote:
>>> Jon Smirl wrote:
>>>> Also, how do you create the devices for each remote? You would need to
>>>> create these devices before being able to do EVIOCSKEYCODE to them.
>>> The input subsystem creates devices on behalf of input drivers. �(Kernel
>>> drivers, that is. �Userspace drivers are per se not affected.)
>>
>> We have one IR receiver device and multiple remotes. How does the
>> input system know how many devices to create corresponding to how many
>> remotes you have?
>
> If several remotes are to be used on the same receiver, then they
> necessarily need to generate different scancodes, don't they? �Otherwise
> the input driver wouldn't be able to route their events to the
> respective subdevice. �But if they do generate different scancodes,
> there is no need to create subdevices just for EVIOCSKEYCODE's sake. (It
> might still be desirable to have subdevices for other reasons perhaps.)
Multiple remotes will have duplicate buttons (1, 2 ,3, power, mute,
etc) these should get mapped into the standard keycodes. You need to
devices to key things straight.
Push button 1 on Remote A. That should generate a KP_1 on the evdev
interface for that remote.
Push button 1 on Remote B. That should generate a KP_1 on the evdev
interface for that remote.
Scenario for this - a mutifunction remote that is controlling two
different devices/apps. In one mode the 1 might be a channel number,
in the other mode it might be a telephone number.
The user may chose to make button 1 on both remote A/B map to KP_1 on
a single interface.
Scenario for this - I want to use two different remotes to control a
single device.
---------------------
I handled that in configds like this:
/configfs - mount the basic configfs
/configfs/remotes (created by loading IR support)
mkdir /configfs/remotes/remote_A - this causes the input subdevice to
be created, the name of it appears in the created directory.
--- this entry really shouldn't be called "remote" it should be named
"application" . Then you build map entries under it for the keycodes
the app knows about. Nothing prevents you from adding entries that map
both Remote_A_1 and Remote_B_1 to KP_1.
-- it's not sufficient to support a single application. I might be
running mythtv, a voip phone, home automation, etc all using a remote.
By switching modes on a multifunction remote I can switch apps.
mkdir /configfs/remotes/remote_A/... - now build the mapping entires.
> --
> Stefan Richter
> -=====-==--= =-== ===--
> http://arcgraph.de/sr/
>
--
Jon Smirl
jons...@gmail.com
Stefan Richter
> On Sat, Nov 28, 2009 at 3:29 PM, Stefan Richter
> <ste...@s5r6.in-berlin.de> wrote:
>> Jon Smirl wrote:
>>> We have one IR receiver device and multiple remotes. How does the
>>> input system know how many devices to create corresponding to how many
>>> remotes you have?
>> If several remotes are to be used on the same receiver, then they
>> necessarily need to generate different scancodes, don't they? Otherwise
I referred to scancodes, not keycodes.
>> the input driver wouldn't be able to route their events to the
>> respective subdevice. But if they do generate different scancodes,
>> there is no need to create subdevices just for EVIOCSKEYCODE's sake. (It
>> might still be desirable to have subdevices for other reasons perhaps.)
>
> Multiple remotes will have duplicate buttons (1, 2 ,3, power, mute,
> etc) these should get mapped into the standard keycodes. You need to
> devices to key things straight.
>
> Push button 1 on Remote A. That should generate a KP_1 on the evdev
> interface for that remote.
> Push button 1 on Remote B. That should generate a KP_1 on the evdev
> interface for that remote.
>
> Scenario for this - a mutifunction remote that is controlling two
> different devices/apps. In one mode the 1 might be a channel number,
> in the other mode it might be a telephone number.
>
> The user may chose to make button 1 on both remote A/B map to KP_1 on
> a single interface.
>
> Scenario for this - I want to use two different remotes to control a
> single device.
>
> ---------------------
>
> I handled that in configds like this:
> /configfs - mount the basic configfs
> /configfs/remotes (created by loading IR support)
> mkdir /configfs/remotes/remote_A - this causes the input subdevice to
> be created, the name of it appears in the created directory.
[...]
I'm lost. If there are two remotes sending to a single receiver, and
their sets of scancodes do not overlap, then all is fine. You can map
either set of scancodes to keycodes independently. But if their ranges
of scancodes do overlap, then even the creation of subdevices does not
help --- the driver has no way to tell which of the remotes sent the
signal in order to select the corresponding input subdevice, does it?
--
Stefan Richter
-=====-==--= =-== ===--
http://arcgraph.de/sr/
--
Jon Smirl
You can do this, but now the events from both remotes are occurring on
a single evdev device. If I assign Remote_A_1 to KP_1 what am I going
to assign to Remote_B_1?
> of scancodes do overlap, then even the creation of subdevices does not
> help --- the driver has no way to tell which of the remotes sent the
> signal in order to select the corresponding input subdevice, does it?
The scancodes are always unique even among different remotes.
I have three apps: mythtv, voip and home automation. How can I use a
remote(s) to control these three apps? The concept of keyboard focus
doesn't map very well to remote controls.
My idea was to create an evdev device for each app:
mythtv - Remote_A_1 mapped KP_1, etc
voip - Remote_B_1 mapped KP_1, etc
home automation - etc
Note that there probably aren't really three remotes (A,B,C), it a
multi-function remote. Picking a different context on a multi-function
remote doesn't generate an event.
> --
> Stefan Richter
> -=====-==--= =-== ===--
> http://arcgraph.de/sr/
>
--
Jon Smirl
jons...@gmail.com
Jon Smirl
devices and forty keys. Each of the five devices can transmit 0-9,
power, volume, etc. It transmits 5*40 = 200 unique scancodes.
I want the five devices to correspond to five apps. What's the plan
for splitting those 200 scancodes into the five apps?
I did it by creating five evdev devices each mapping 40 scancodes.
That's lets me reuse KP_1 for each of the five apps.
Andy Walls
On Sat, 2009-11-28 at 12:37 -0500, Jon Smirl wrote:
> On Sat, Nov 28, 2009 at 12:35 PM, Krzysztof Halasa <k...@pm.waw.pl> wrote:
> > Jon Smirl <jons...@gmail.com> writes:
> >
> >> There are two very basic things that we need to reach consensus on first.
> >>
> >> 1) Unification with mouse/keyboard in evdev - put IR on equal footing.
The only thing this buys for the user is remote/products bundles that
work out of the box. That can only be a solution for the 80% case.
I don't hear users crying out "Please integrate IR with the input
system". I do hear users say "I want my remote to work", and "How can I
make my remote work?". Users are not specifically asking for this
integration of IR and the input system - a technical nuance. If such a
tecnical desire-ment drives excessive rework, I doubt anyone will care
enough about IR to follow through to make a complete system.
What does "equal footing" mean as an incentive anyway? The opportunity
to reimplement *everything* that exists for IR already over again in
kernel-space for the sake of developer technical desires? That's just a
lot of work for "not invented here" syndrome. IR transceivers are
arguably superior to keyboards and mice anyway because they can transmit
data too.
> >> 2) Specific tools (xmodmap, setkeycodes, etc or the LIRC ones) or
> >> generic tools (ls, mkdir, echo) for configuration
> >
> > I think we can do this gradually:
> > 1. Merging the lirc drivers. The only stable thing needed is lirc
> > interface.
>
> Doing that locks in a user space API that needs to be supported
> forever. We need to think this API through before locking it in.
No one get things right the first time - No one.
Most designs are iterated with prototypes in the commercial world.
Prototypes keep costs low so you can throw it away easily and try a new
approach, if the current approach is not panning out
Only governements try to get everything right on the first go. It takes
them too long and the end product is usually still hosed.
Whatever gets developed won't be locked in for 20 years, that's absurd.
Technology moves on 6 month to two year cycles. Linux changes ABIs too.
V4L transitioned from V4L1 to V4L2 and that's happened in less than 20
years for a much more complex set of devices with a more varied set of
userspace apps.
Regards,
Andy
> > 2. Changing IR input layer interface ("media" drivers and adding to lirc
> > drivers).
> > --
> > Krzysztof Halasa
--
Mike Lampard
> On Fri, Nov 27, 2009 at 2:45 AM, Christoph Bartelmus
>
> <chri...@bartelmus.de> wrote:
> > 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?
>
> Take advantage of the fact that we don't have a twenty year old legacy
> API already in the kernel. Design an IR API that uses current kernel
> systems. Christoph, ignore the code I wrote and make a design proposal
> that addresses these goals...
>
> 1) Unified input in Linux using evdev. IR is on equal footing with
> mouse and keyboard.
I think this a case where automating setup can be over-emphasised (in the
remote-as-keyboard case).
Apologies in advance if I've misunderstood the idea of utilising the 'input
subsystem' for IR. If the plan is to offer dedicated IR events via a yet-to-
be-announced input event subsystem and to optionally disallow acting as a
keyboard via a module option or similar then please ignore the following.
Whilst having remotes come through the input subsystem might be 'the correct
thing' from a purely technical standpoint, as an end-user I find the use-case
for remotes completely different in one key aspect: Keyboards and mice are
generally foreground-app input devices, whereas remotes are often controlling
daemons sitting in the background piping media through dedicated devices. As
an example I have a VDR instance running in the background on my desktop
machine outputting to a TV in another room via a pci mpeg decoder - I
certainly don't want the VDR remote control interacting with my X11 desktop in
any way unless I go out of my way to set it up to do so, nor do I want it
interacting with other applications (such as MPD piping music around the
house) that are controlled via other remotes in other rooms unless specified.
Setting this up with Lircd was easy, how would a kernel-based proposal handle
this?
Regards
Mike
> 2) plug and play for basic systems - you only need an external app for
> scripting
> 3) No special tools - use mkdir, echo, cat, shell scripts to
> build maps
> 4) Use of modern Linux features like sysfs, configfs and udev.
> 5) Direct multi-app support - no daemon
> 6) Hide timing data from user as much as possible.
>
> What are other goals for this subsystem?
>
> Maybe we decide to take the existing LIRC system as is and not
> integrate it into the input subsystem. But I think there is a window
> here to update the LIRC design to use the latest kernel features. We
> don't want to build another /dev/mouse and have to rip it out in five
> years.
>
> > 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
>
> This is good input.
Andy Walls
> > Jon Smirl <jons...@gmail.com> writes:
> >
> >> There are two very basic things that we need to reach consensus on first.
> >>
> >> 1) Unification with mouse/keyboard in evdev - put IR on equal footing.
BTW, circa 1995 my serial mouse "Just Worked" in Linux. Sometime around
the release of Fedora Core 3 or 4, serial mice stopped being well
supported as input devices AFAICT. (I still have a dual boot
Windows95/Linux machine with a serial mouse because it has ISA slots.)
Are serial port connected IR devices going to see the same fate in this
model?
Why not consider IR devices as bi-directional communications devices vs.
input devices like mice or keyboards? Theoretically the TTY layer with
line discipline modules for underlying IR hardware could also interface
IR devices to user space.
Sorry, the input subsystem cannot meet all the end user IR requirements.
I doubt it could easily support all the current user space only IR
drivers moving into the kernel. I suspect the serial port connected IR
devices will be deemed "too hard" and IR Tx as "not input" and dropped
on the floor.
The more I think about IR integration with input, the more I think any
effort beyond the plug-and-plug for default configurations is a waste of
time and effort. Something more is needed to handle the transmitters
and serial connected IRs. It's also too convenient to access USB IR
hardware from existing userspace drivers to bother porting into the
kernel.
Regards,
Andy
Dmitry Torokhov
> Jon,
>
> On Sat, 2009-11-28 at 12:37 -0500, Jon Smirl wrote:
> > On Sat, Nov 28, 2009 at 12:35 PM, Krzysztof Halasa <k...@pm.waw.pl> wrote:
> > > Jon Smirl <jons...@gmail.com> writes:
> > >
> > >> There are two very basic things that we need to reach consensus on first.
> > >>
> > >> 1) Unification with mouse/keyboard in evdev - put IR on equal footing.
>
> The only thing this buys for the user is remote/products bundles that
> work out of the box. That can only be a solution for the 80% case.
>
> I don't hear users crying out "Please integrate IR with the input
> system". I do hear users say "I want my remote to work", and "How can I
> make my remote work?". Users are not specifically asking for this
> integration of IR and the input system - a technical nuance.
Right, but if remotes work users did not care if we went through 20
revisions of the interface and how much effort was wasted. When we
talking about users here we do talk about application developers mostly,
not the consumers.
Well, consumers would bennefit of plug and play and proper power
management too.
--
Dmitry
Dmitry Torokhov
> On Sat, 2009-11-28 at 12:37 -0500, Jon Smirl wrote:
> > On Sat, Nov 28, 2009 at 12:35 PM, Krzysztof Halasa <k...@pm.waw.pl> wrote:
> > > Jon Smirl <jons...@gmail.com> writes:
> > >
> > >> There are two very basic things that we need to reach consensus on first.
> > >>
> > >> 1) Unification with mouse/keyboard in evdev - put IR on equal footing.
>
> BTW, circa 1995 my serial mouse "Just Worked" in Linux. Sometime around
> the release of Fedora Core 3 or 4, serial mice stopped being well
> supported as input devices AFAICT. (I still have a dual boot
> Windows95/Linux machine with a serial mouse because it has ISA slots.)
>
serport + sermouse combo should work well. At least I don't get any bug
reports ;P
> Are serial port connected IR devices going to see the same fate in this
> model?
>
>
> Why not consider IR devices as bi-directional communications devices vs.
> input devices like mice or keyboards? Theoretically the TTY layer with
> line discipline modules for underlying IR hardware could also interface
> IR devices to user space.
>
> Sorry, the input subsystem cannot meet all the end user IR requirements.
Again, what end users are you taling about here? An application that
wants to prcess key (or button) presses? Or something entirely
different, lice lirc itself?
> I doubt it could easily support all the current user space only IR
> drivers moving into the kernel. I suspect the serial port connected IR
> devices will be deemed "too hard" and IR Tx as "not input" and dropped
> on the floor.
>
>
> The more I think about IR integration with input, the more I think any
> effort beyond the plug-and-plug for default configurations is a waste of
> time and effort. Something more is needed to handle the transmitters
> and serial connected IRs. It's also too convenient to access USB IR
> hardware from existing userspace drivers to bother porting into the
> kernel.
Having support 2 different interfaces for regular applications is also a
waste of time and effort. The applications who don;t care about IRC
protocol decoding should be able to just work with standard input
interface.
--
Dmitry
Dmitry Torokhov
> I'm looking at a Sony multi-function remote right now. It has five
> devices and forty keys. Each of the five devices can transmit 0-9,
> power, volume, etc. It transmits 5*40 = 200 unique scancodes.
>
> I want the five devices to correspond to five apps. What's the plan
> for splitting those 200 scancodes into the five apps?
>
> I did it by creating five evdev devices each mapping 40 scancodes.
> That's lets me reuse KP_1 for each of the five apps.
>
KEY_NUMERIC_1 please (which should not be affected by numlock state).
--
Dmitry
Dmitry Torokhov
Why would that be different really? On my keyboard there is a key for
e-mail application (and many others) - what HID calls Application Launch
keys IIRC. There also application control keys and system control keys,
KEY_COFFEE aka KEY_SCREENLOCK. Those are not to be consumed by
foreground application but by daemons/session-wide application.
--
Dmitry
Mike Lampard
and are not associated with any user-initiated sessions (X login etc) - they
are not X11 clients. Their only input is via Lircd. Conversely todays
Xserver (if I read my logfiles correctly) consumes all input event devices by
default, turning them into keypresses for its client apps. This is exactly
the wrong behaviour for my use-case. In order to ensure that my daemons
receive their input I must first ensure that X doesn't receive those events -
assuming this is possible it still complicates matters further than they are
today (I'd need a simple way of automatically differentiating between remote
devices and keyboard devices) .
Mike
Dmitry Torokhov
But the setup you described only works for you because lirc is the only
consumer using the device _for now_. As soon as there are more users you
will have to solve the same isssue as with evdev being consumed but
different applications. As soon as somebody says "gosh, I really don't
want my KDE application to depend on lircm why does not X provide RC
data the same way it provides key presses?" your setup goes south.
As to how to solve such specific needs - there could be different
solutions. EVIOCGRAB can be used to gain exclusive access (but that
again breaks when there appears another application wanting exclusive
access). Applications can limit themselves to opening only specific
event devices (and igonre others).
--
Dmitry
Christoph Bartelmus
on 28 Nov 09 at 18:21, Krzysztof Halasa wrote:
[...]
>> This remote uses RC-5. But some of the developers must have thought that
>> it may be a smart idea to use 14 bits instead the standard 13 bits for
>> this remote. In LIRC you won't care, because this is configurable and
>> irrecord will figure it out automatically for you. In the proposed kernel
>> decoders I have seen until now, you will have to treat this case specially
>> in the decoder because you expect 13 bits for RC-5, not 14.
> Well, the 14-bit RC5 is de-facto standard for some time now. One of the
> start bits, inverted, now functions as the MSB of the command code.
> 13-bit receiver implementations (at least these aimed at "foreign"
> remotes) are obsolete.
Ah, sorry. I didn't mean the extension of the command code by inverting
one of the start bits.
The Streamzap really uses one more bit.
In the LIRC world the RC5 start bit which is fixed to "1" is not counted
as individual bit. So translated to your notation, the Streamzap uses 15
bits, not 14 like the extended RC-5 or 13 like the original RC-5...
Christoph
Christoph Bartelmus
on 28 Nov 09 at 21:29, Stefan Richter wrote:
> Jon Smirl wrote:
>> On Sat, Nov 28, 2009 at 2:45 PM, Stefan Richter
>> <ste...@s5r6.in-berlin.de> wrote:
>>> Jon Smirl wrote:
>>>> Also, how do you create the devices for each remote? You would need to
>>>> create these devices before being able to do EVIOCSKEYCODE to them.
>>> The input subsystem creates devices on behalf of input drivers. (Kernel
>>> drivers, that is. Userspace drivers are per se not affected.)
>>
>> We have one IR receiver device and multiple remotes. How does the
>> input system know how many devices to create corresponding to how many
>> remotes you have?
> If several remotes are to be used on the same receiver, then they
> necessarily need to generate different scancodes, don't they? Otherwise
> the input driver wouldn't be able to route their events to the
> respective subdevice.
Consider this case:
Two remotes use different protocols. The scancodes after decoding happen
to overlap.
Just using the scancodes you cannot distinguish between the remotes.
You'll need to add the protocol information to be able to solve this which
complicates the setup.
In LIRC this is solved by having protocol parameters and scancode mapping
in one place.
Christoph
Christoph Bartelmus
on 28 Nov 09 at 09:21, Mauro Carvalho Chehab wrote:
> Hi Christoph,
>
> Christoph Bartelmus wrote:
>>> Maybe we decide to take the existing LIRC system as is and not
>>> integrate it into the input subsystem. But I think there is a window
>>> here to update the LIRC design to use the latest kernel features.
>>
>> If it ain't broke, don't fix it.
[...]
> So, even not being broken, the subsystem internal media API's changed
> a lot during the last years, and there are still several new changes
> on our TODO list.
>
> So, I'd say that if we can do it better, then let's do it.
I'm not against improving things.
If there are feature request that cannot be handled with an interface, it
has to be extended or redesigned. But currently the LIRC interface
supports all features that came up until now since many years.
I just don't want to change a working interface just because it could be
also implemented in a different way, but having no other visible advantage
than using more recent kernel features.
[...]
>> For devices that do the decoding in hardware, the only thing that I don't
>> like about the current kernel implementation is the fact that there are
>> mapping tables in the kernel source. I'm not aware of any tools that let
>> you change them without writing some keymaps manually.
[...]
> Still, I prefer first to migrate all drivers to use the full scancode and
> re-generate the keymaps before such step.
Good to see that this is in the works.
[...]
>> With the approach that you
>> suggested for the in-kernel decoder, this device simply will not work for
>> anything but RC-5. The devil is in all the details.
> I haven't seen such limitations on his proposal. We currently have in-kernel
> decoders for NEC, pulse-distance, RC4 protocols, and some variants. If
> non-RC5 decoders are missing, we need for sure to add them.
That was not my point. If you point a NEC remote at the Igor USB device,
you won't be able to use a NEC decoder because the device will swallow
half of the bits. LIRC won't care unless the resulting scancodes are
identical.
Granted, this is an esoteric arguement, because this device is utter
garbage.
[...]
>> If we decide to do the
>> decoding in-kernel, how long do you think this solution will need to
>> become really stable and mainline? Currently I don't even see any
>> consensus on the interface yet. But maybe you will prove me wrong and it's
>> just that easy to get it all working.
> The timeframe to go to mainline will basically depend on taking a decision
> about the API and on people having time to work on it.
>
> Providing that we agree on what we'll do, I don't see why not
> adding it on staging for 2.6.33 and targeting to have
> everything done for 2.6.34 or 2.6.35.
The problem that I see here is just that even when we have very talented
people working on this, that put together all resources, we won't be able
to cover all the corner cases with all the different receivers and remote
control protocols out there. It will still require lots of fine-tuning
which was done in LIRC over the years.
>> I also understand that people want to avoid dependency on external
>> userspace tools. All I can tell you is that the lirc tools already do
>> support everything you need for IR control. And as it includes a lot of
>> drivers that are implemented in userspace already, LIRC will just continue
>> to do it's work even when there is an alternative in-kernel.
> The point is that for simple usage, like an user plugging his new USB stick
> he just bought, he should be able to use the shipped IR without needing to
> configure anything or manually calling any daemon. This currently works
> with the existing drivers and it is a feature that needs to be kept.
Admittedly, LIRC is way behind when it comes to plug'n'play.
Christoph Bartelmus
on 27 Nov 09 at 12:49, Jon Smirl wrote:
[...]
> Christoph, take what you know from all of the years of working on LIRC
> and design the perfect in-kernel system. This is the big chance to
> redesign IR support and get rid of any past mistakes. Incorporate any
> useful chunks of code and knowledge from the existing LIRC into the
> new design. Drop legacy APIs, get rid of daemons, etc. You can do this
> redesign in parallel with existing LIRC. Everyone can continue using
> the existing code while the new scheme is being built. Think of it as
> LIRC 2.0. You can lead this design effort, you're the most experience
> developer in the IR area.
This is a very difficult thing for me to do. I must admit that I'm very
biased.
Because lircd is the only userspace application that uses the LIRC kernel
interface, we never had any problems changing the interface when needed.
I can't say there's much legacy stuff inside. I'm quite happy with the
interface.
The other thing is that I can't really move the decoder from userspace to
kernel because there are way too many userspace drivers that do require a
userspace decoder. LIRC also is running on FreeBSD, MacOS and even Cygwin.
So letting the userspace drivers take advantage of a potential Linux in-
kernel decoder is not an option for me either.
I'm having my 'LIRC maintainer' hat on mostly during this discussion and I
do understand that from Linux kernel perspective things look different.
> Take advantage of this window to make a
> design that is fully integrated with Linux - put IR on equal footing
> with the keyboard and mouse as it should be.
That's a question that I have not answered for myself concludingly.
Is a remote control really on exactly the same level as a keyboard or
mouse?
Alan Cox
Correct X11 just talked to the serial ports. In fact that is still the
way to configure it if you want any sanity in life.
> and serial connected IRs. It's also too convenient to access USB IR
> hardware from existing userspace drivers to bother porting into the
> kernel.
Userspace needs a way to identify IR hardware and to interface with it
using the right protocol. It's not clear the kernel needs to provide
anything more than minimal hardware interfaces in most case - be that
serial, libusb, ...
Mauro Carvalho Chehab
The above struct doesn't fit for the already existing in-kernel drivers, since
you may have more than one IR driver on kernel. I have some machines here with
3 or 4 different input cards, each with their own IR hardware. How are you
supposing to associate a created Remote Controller with the corresponding driver?
With EVIOSKEYCODE, it is as simple as directing the ioctl to the corresponding
evdev interface.
Cheers,
Mauro.
Mauro Carvalho Chehab
> I'm looking at a Sony multi-function remote right now. It has five
> devices and forty keys. Each of the five devices can transmit 0-9,
> power, volume, etc. It transmits 5*40 = 200 unique scancodes.
>
> I want the five devices to correspond to five apps. What's the plan
> for splitting those 200 scancodes into the five apps?
>
> I did it by creating five evdev devices each mapping 40 scancodes.
> That's lets me reuse KP_1 for each of the five apps.
>
>
In this case, the evdev interface won't solve the issue alone. Some sort
of userspace tool will need to identify what application is expecting that
code and redirect it to that application.
IMO, the biggest LIRC benefit over a pure evdev interface, from user's perspective,
is that it can redirect a keycode to a specific application.
Yet, I don't see why your configfs proposal will solve this issue, as userspace
will keep receiving duplicated KET_
Mauro Carvalho Chehab
In this case, the evdev interface won't solve the issue alone. Some sort
of userspace tool will need to identify what application is expecting that
code and should redirect it to that application. So, you'll basically need
a table like:
scancode -> application PID | keycode
And, IMO, such mapping schema is better handled at userspace.
Yet, I don't see how your configfs proposal will solve this issue, as userspace
will keep receiving duplicated events (in different evdev interfaces, but
still the same keycode will be sent to userspace). You might be
considering that each application will open a different set of evdev interfaces,
and getting exclusive locks, but this will require a setup per-application, or
to have some proxy program that will open all different evdev interfaces and do the
keycode redirects.
On a scenario that different scancodes will produce the same KEY events, but
each duplicated scancode will be sent to a different application, the better
would be to have an evdev interface that will output directly the scancode
and let an userspace program to "focus" the keystroke to the corresponding
application.
IMHO, the biggest LIRC benefit over a pure evdev interface, from user's
perspective, is that it can redirect a keycode to a specific application.
Cheers,
Mauro.
Maxim Levitsky
> > BTW, circa 1995 my serial mouse "Just Worked" in Linux. Sometime around
>
> Correct X11 just talked to the serial ports. In fact that is still the
> way to configure it if you want any sanity in life.
>
> > and serial connected IRs. It's also too convenient to access USB IR
> > hardware from existing userspace drivers to bother porting into the
> > kernel.
>
> Userspace needs a way to identify IR hardware and to interface with it
> using the right protocol. It's not clear the kernel needs to provide
> anything more than minimal hardware interfaces in most case - be that
> serial, libusb, ...
Exactly.
As it currently stands, kernel provides lircd the pulse/space timing,
lirc parses that, and sends input events via uinput.
lircd behaves just like an userspace driver, and the biggest advantage
is that it can access its configuration directly, unlike kernel solution
that will have to use some configfs hack.
It can use its own older interface, but that is now optional.
Also its not that hard to make lirc scan is database and adapt to the
remote that is used.
This should give the user absolutely zero configuration.
Instead, there is strong push to put lircd, the userspace daemon's
functionality into kernel.
This has zero advantages besides good developer feeling that "My system
has one less daemon..."
Best regards,
Maxim Levitsky
Ray Lee
> This has zero advantages besides good developer feeling that "My system
> has one less daemon..."
Surely it's clear that having an unnecessary daemon is introducing
another point of failure? Reducing complexity is not just its own
reward in a 'Developer Feel Good' way.
If decoding can *only* be sanely handled in user-space, that's one
thing. If it can be handled in kernel, then that would be better.
Alan Cox
> thing. If it can be handled in kernel, then that would be better.
Why ?
I can compute fast fourier transforms in the kernel but that doesn't make
it better than doing it in user space. I can write web servers in the
kernel and the same applies.
Alan
Jon Smirl
>> BTW, circa 1995 my serial mouse "Just Worked" in Linux. �Sometime around
>
> Correct X11 just talked to the serial ports. In fact that is still the
> way to configure it if you want any sanity in life.
>
>> and serial connected IRs. �It's also too convenient to access USB IR
>> hardware from existing userspace drivers to bother porting into the
>> kernel.
>
> Userspace needs a way to identify IR hardware and to interface with it
> using the right protocol. It's not clear the kernel needs to provide
> anything more than minimal hardware interfaces in most case - be that
> serial, libusb, ...
That's a description of the current system and it is driver chaos.
Half of the drivers are in user space and there are two different
classes of kernel driver - LIRC and V4L.
A lot of the hardware doesn't identify itself.
There are two types of IR data in use - pulse timing and decoded protocol.
IR is an input device. We have a nice evdev input subsystem and it has
been demonstrated that IR can work with it.
Everybody keeps complaining that they want IR to "just work".
Consolidating all of this (under 50K of code) driver support in the
kernel is the way to make it "just work".
For example. Some IR devices only record pulse timing data. There are
various protocols - RC5, RC6, etc for turning these pulse timing into
a decode IR command. This is about 20K of code. Does it really make
sense to create a device, push this data out into user space, decode
it there, then inject the results back into the kernel (uinput) for
further processing by the input subsystem?
This decoding is getting done in user space because half of the IR
drivers are in user space. But the other half of them aren't in user
space and that set can't work in user space. Most of the user space
drivers can be pushed into the kernel where they'll automatically load
when the device is detected.
Some of the drivers can't be moved like the IR over ALSA. But is
attaching an IR diode to the mic input of your sound card really a
device or is it a hack that should be dealt with in user space?
Another type is IR hardware that toggles the DTR output of a serial
port at 40Khz to make a signal. Same thing is done with parallel
ports. Those force the system into a bit-banging timing loop for
1/10th second.
--
Jon Smirl
jons...@gmail.com
Ray Lee
>> If decoding can *only* be sanely handled in user-space, that's one
>> thing. If it can be handled in kernel, then that would be better.
>
> Why ?
>
> I can compute fast fourier transforms in the kernel but that doesn't make
> it better than doing it in user space.
Of course not.
> I can write web servers in the kernel and the same applies.
I'm not so young as to not recall Tux. That was again a bad idea, for
the same reason. It introduced unnecessary complexity. Enabling
userspace to be able to service web requests faster improved all
user-space code. Yay.
The question is which solution is more complex, the current one that
requires userspace to be an active participant in the decoding, so
that we can handle bare diodes hooked up to a sound-card, or having
the kernel do decode for the sane devices and providing some fall-back
for broken hardware. The former has the advantage of being flexible at
the cost of increased fragility and surface area for security, and
latency in responding to events, the latter has the problem of
requiring two different decoding paths to be maintained, at least if
you want to support odd-ball hardware.
Jon is asking for an architecture discussion, y'know, with use cases.
Maxim seems to be saying it's obvious that what we have today works
fine. Except it doesn't appear that we have a consensus that
everything is fine, nor an obvious winner for how to reduce the
complexity here and keep the kernel in a happy, maintainable state for
the long haul.
Who knows, perhaps I misunderstood the dozens of messages up-thread --
wouldn't be the first time, in which case I'll shut up and let you get
back to work.
Alan Cox
> classes of kernel driver - LIRC and V4L.
> A lot of the hardware doesn't identify itself.
> There are two types of IR data in use - pulse timing and decoded protocol.
>
> IR is an input device. We have a nice evdev input subsystem and it has
> been demonstrated that IR can work with it.
Evdev allows userspace to feed events into the kernel.
> Everybody keeps complaining that they want IR to "just work".
> Consolidating all of this (under 50K of code) driver support in the
> kernel is the way to make it "just work".
We have things called "Libraries" that unlike kernel code run out of a
secure context, can be paged and shared by applications dynamically.
Also the data rate of IR controllers puts it into the realm where the
kernel doesn't need to be involved, in fact you could turn them into
evdev events via user space quite acceptably, or even into meaningful
actions and onto dbus.
> For example. Some IR devices only record pulse timing data. There are
> various protocols - RC5, RC6, etc for turning these pulse timing into
> a decode IR command. This is about 20K of code. Does it really make
> sense to create a device, push this data out into user space, decode
> it there, then inject the results back into the kernel (uinput) for
> further processing by the input subsystem?
Does it really make sense to put big chunks of protocol decoding crap for
an interface which runs at about 1 character per second on a good day
into the kernel ? Does it really make sense ot move 50K of code from user
context to kernel context where it must meet strict security
requirements, be extensively audited and cannot be paged. For embedded
users will also have to be highly modular so no unused bits are loaded.
> This decoding is getting done in user space because half of the IR
> drivers are in user space. But the other half of them aren't in user
> space and that set can't work in user space. Most of the user space
> drivers can be pushed into the kernel where they'll automatically load
> when the device is detected.
So you proposed to write another ton of new drivers in kernel space for
these only devices supported by user space, portably and to test and
submit them all. If you can't persuade the maintainera of all those
drivers to do so you don't appear to have a credible proposal.
> attaching an IR diode to the mic input of your sound card really a
> device or is it a hack that should be dealt with in user space?
It's a device. There is no divide between "hack" and "device", as anyone
who ever worked on the Mac68K can assure you ;)
> Another type is IR hardware that toggles the DTR output of a serial
> port at 40Khz to make a signal. Same thing is done with parallel
> ports. Those force the system into a bit-banging timing loop for
> 1/10th second.
We have people who run wireless like that, people who ran SCSI and IDE
like that. In the embedded world its the norm. If you sell 100,000
devices then saving that part, wiring and board space is often the right
choice. That kind of stuff needs doing in user space not kernel.
You stated the real problem at the start - devices don't identify
themselves well. That doesn't seem to be a kernel problem other than for
kernel drivers perhaps exposing more information on themselves via sysfs.
Alan Cox
> Maxim seems to be saying it's obvious that what we have today works
> fine. Except it doesn't appear that we have a consensus that
> everything is fine, nor an obvious winner for how to reduce the
> complexity here and keep the kernel in a happy, maintainable state for
> the long haul.
The important point is that this is not an A or B discussion. There are
lots of ways to tackle it that are neither. If you look at things like
complex video format handling it is done in user space but with an
infrastructure to handle it.
I don't believe putting it in the kernel is the alternative to the
current setup. Cleaning up the way what we have today is presented to
applications is perfectly possible without a whole new pile of kernel
crap, because evdev was designed sensibly in the first place to allow
userspace added events.
Jon Smirl
>> Jon is asking for an architecture discussion, y'know, with use cases.
>> Maxim seems to be saying it's obvious that what we have today works
>> fine. Except it doesn't appear that we have a consensus that
>> everything is fine, nor an obvious winner for how to reduce the
>> complexity here and keep the kernel in a happy, maintainable state for
>> the long haul.
>
> The important point is that this is not an A or B discussion. There are
> lots of ways to tackle it that are neither. If you look at things like
> complex video format handling it is done in user space but with an
> infrastructure to handle it.
>
> I don't believe putting it in the kernel is the alternative to the
> current setup. Cleaning up the way what we have today is presented to
> applications is perfectly possible without a whole new pile of kernel
> crap, because evdev was designed sensibly in the first place to allow
> userspace added events.
So we're just back to the status quo of last year which is to do
nothing except some minor clean up.
We'll be back here again next year repeating this until IR gets
redesigned into something fairly invisible like keyboard and mouse
drivers.
--
Jon Smirl
jons...@gmail.com
Alan Cox
> nothing except some minor clean up.
Which in itself is vastly preferable to some grandiose scheme that turns
out to be wrong.
And no it's not a back to the status quo, it's a request to discuss the
actual problems and options not to simply try and force your chosen
solution down the throats of everyone else.
Christoph Bartelmus
on 29 Nov 09 at 14:16, Jon Smirl wrote:
> On Sun, Nov 29, 2009 at 2:04 PM, Alan Cox <al...@lxorguk.ukuu.org.uk> wrote:
>>> Jon is asking for an architecture discussion, y'know, with use cases.
[...]
> So we're just back to the status quo of last year which is to do
> nothing except some minor clean up.
>
> We'll be back here again next year repeating this until IR gets
> redesigned into something fairly invisible like keyboard and mouse
> drivers.
Last year everyone complained that LIRC does not support evdev - so I
added support for evdev.
This year everyone complains that LIRC is not plug'n'play - we'll fix that
'til next year.
There's progress. ;-)
Christoph
Krzysztof Halasa
least?
2. Is there any problem with lirc kernel-user interface?
If the answer for #1 is "yes" and for #2 is "no" then perhaps we merge
the Jarod's lirc patches (at least the core) so at least the
non-controversial part is done?
Doing so doesn't block improving input layer IR interface, does it?
--
Krzysztof Halasa
Jon Smirl
> 1. Do we agree that a lirc (-style) kernel-user interface is needed at
> � least?
>
> 2. Is there any problem with lirc kernel-user interface?
Can you consider sending the raw IR data as a new evdev message type
instead of creating a new device protocol?
evdev protects the messages in a transaction to stop incomplete
messages from being read.
You might also want to use evdev capabilities to describe what the
hardware can do. These were the capabilities I had made up:
#define IR_CAP_RECEIVE_BASEBAND 0
#define IR_CAP_RECEIVE_36K 1
#define IR_CAP_RECEIVE_38K 2
#define IR_CAP_RECEIVE_40K 3
#define IR_CAP_RECEIVE_56K 4
#define IR_CAP_SEND_BASEBAND 5
#define IR_CAP_SEND_36K 6
#define IR_CAP_SEND_38K 7
#define IR_CAP_SEND_40K 8
#define IR_CAP_SEND_56K 9
#define IR_CAP_XMITTER_1 10
#define IR_CAP_XMITTER_2 11
#define IR_CAP_XMITTER_3 12
#define IR_CAP_XMITTER_4 13
#define IR_CAP_RECEIVE_RAW 14
#define IR_CAP_SEND_RAW 15
> If the answer for #1 is "yes" and for #2 is "no" then perhaps we merge
> the Jarod's lirc patches (at least the core) so at least the
> non-controversial part is done?
>
> Doing so doesn't block improving input layer IR interface, does it?
> --
> Krzysztof Halasa
>
--
Jon Smirl
jons...@gmail.com
Dmitry Torokhov
> 1. Do we agree that a lirc (-style) kernel-user interface is needed at
> least?
>
> 2. Is there any problem with lirc kernel-user interface?
>
> If the answer for #1 is "yes" and for #2 is "no" then perhaps we merge
> the Jarod's lirc patches (at least the core) so at least the
> non-controversial part is done?
Isn't the meat of Jarod's patch the lirc interface?
--
>
Dmitry
Dmitry Torokhov
> On Sun, Nov 29, 2009 at 3:27 PM, Krzysztof Halasa <k...@pm.waw.pl>
> wrote:
>> 1. Do we agree that a lirc (-style) kernel-user interface is needed
>> at
>> least?
>>
>> 2. Is there any problem with lirc kernel-user interface?
>
> Can you consider sending the raw IR data as a new evdev message type
> instead of creating a new device protocol?
No, I think it would be wrong. Such events are ill-suited for
consumption by regular applications and would introduce the "looping"
interface I described in my other email.
> evdev protects the messages in a transaction to stop incomplete
> messages from being read.
If such property is desired we can add it to the new lirc-like
interface, can't we?
--
>
Dmitry
Jon Smirl
<dmitry....@gmail.com> wrote:
> On Nov 29, 2009, at 12:44 PM, Jon Smirl <jons...@gmail.com> wrote:
>
>> On Sun, Nov 29, 2009 at 3:27 PM, Krzysztof Halasa <k...@pm.waw.pl> wrote:
>>>
>>> 1. Do we agree that a lirc (-style) kernel-user interface is needed at
>>> �least?
>>>
>>> 2. Is there any problem with lirc kernel-user interface?
>>
>> Can you consider sending the raw IR data as a new evdev message type
>> instead of creating a new device protocol?
>
> No, I think it would be wrong. Such events are ill-suited for consumption by
> regular applications and would introduce the "looping" interface I described
> in my other email.
Regular applications are going to ignore these messages. The only
consumer for them is the LIRC daemon. Which is just going to process
them and re-inject the events back into evdev again in a different
form.
IR is an input device, what make it so special that it needs to by
pass this subsystem and implement its own private communications
scheme?
>> evdev protects the messages in a transaction to stop incomplete
>> messages from being read.
>
> If such property is desired we can add it to the new lirc-like interface,
> can't we?
Why do you want to redesign evdev instead of using it?
>
> --
>>
> Dmitry
>
--
Jon Smirl
jons...@gmail.com
Artur Skawina
> an example I have a VDR instance running in the background on my desktop
> machine outputting to a TV in another room via a pci mpeg decoder - I
> certainly don't want the VDR remote control interacting with my X11 desktop in
> any way unless I go out of my way to set it up to do so, nor do I want it
> interacting with other applications (such as MPD piping music around the
> house) that are controlled via other remotes in other rooms unless specified.
>
> Setting this up with Lircd was easy, how would a kernel-based proposal handle
> this?
eg
EV="/dev/input/"$( cd "/sys/class/input" &&
( grep -l 'X10' event*/device/name || grep -l 'X10' event*/device/manufacturer ) |
sed -e 's,/.*,,' )
./vdr [...] -P "remote -i $EV"
This is how it has worked for years, so there's no reason it wouldn't work w/ any
future scheme. The remote buttons normally arrive as normal kbd keys; once an app
grabs the input device corresponding to a remote, it receives the events exclusively.
artur
Dmitry Torokhov
> On Sun, Nov 29, 2009 at 4:29 PM, Dmitry Torokhov
> <dmitry....@gmail.com> wrote:
>> On Nov 29, 2009, at 12:44 PM, Jon Smirl <jons...@gmail.com> wrote:
>>
>>> On Sun, Nov 29, 2009 at 3:27 PM, Krzysztof Halasa <k...@pm.waw.pl>
>>> wrote:
>>>>
>>>> 1. Do we agree that a lirc (-style) kernel-user interface is
>>>> needed at
>>>> least?
>>>>
>>>> 2. Is there any problem with lirc kernel-user interface?
>>>
>>> Can you consider sending the raw IR data as a new evdev message type
>>> instead of creating a new device protocol?
>>
>> No, I think it would be wrong. Such events are ill-suited for
>> consumption by
>> regular applications and would introduce the "looping" interface I
>> described
>> in my other email.
>
> Regular applications are going to ignore these messages. The only
> consumer for them is the LIRC daemon. Which is just going to process
> them and re-inject the events back into evdev again in a different
> form.
>
> IR is an input device, what make it so special that it needs to by
> pass this subsystem and implement its own private communications
> scheme?
So are HID devices (both USB and BT), PS/2 and so on. You are not
arguing for sending unprocessed data from these devices through evdev.
>
>>> evdev protects the messages in a transaction to stop incomplete
>>> messages from being read.
>>
>> If such property is desired we can add it to the new lirc-like
>> interface,
>> can't we?
>
> Why do you want to redesign evdev instead of using it?
>
I just said why in my previous email: looping is a mark of badly
designed interface.
--
Dmitry
Andy Walls
> On Sun, Nov 29, 2009 at 9:28 AM, Maxim Levitsky <maximl...@gmail.com> wrote:
> > This has zero advantages besides good developer feeling that "My system
> > has one less daemon..."
>
> Surely it's clear that having an unnecessary daemon is introducing
> another point of failure?
A failure in a userspace IR daemon is worst case loss of IR
functionality.
A failure in kernel space can oops or panic the machine.
> Reducing complexity is not just its own
> reward in a 'Developer Feel Good' way.
No complexity is being reduced here. It's being shoved from one side of
a fence to another. A bad part about the proposed move is that in user
space, user address space is fairly isolated from other applications and
separate from kernel space. Partitioning reduces complexity and the
impact of failures. Moving things into kernel space just adds more to
the pile of code; it should have a good reason for being there.
> If decoding can *only* be sanely handled in user-space, that's one
> thing. If it can be handled in kernel, then that would be better.
Why does the address space in which decoding is performed make the
decoding process better or worse? The in kernel infrastructre and
restrictions add constraints to a decoding implementation. Userspace is
much more flexible.
Regards,
Andy
Andy Walls
> Hi,
>
> on 29 Nov 09 at 14:16, Jon Smirl wrote:
> > On Sun, Nov 29, 2009 at 2:04 PM, Alan Cox <al...@lxorguk.ukuu.org.uk> wrote:
> >>> Jon is asking for an architecture discussion, y'know, with use cases.
> [...]
> > So we're just back to the status quo of last year which is to do
> > nothing except some minor clean up.
> >
> > We'll be back here again next year repeating this until IR gets
> > redesigned into something fairly invisible like keyboard and mouse
> > drivers.
>
> Last year everyone complained that LIRC does not support evdev - so I
> added support for evdev.
>
> This year everyone complains that LIRC is not plug'n'play - we'll fix that
> 'til next year.
V4L-DVB is also making progress on the enumeration front. At least for
V4L devices a new media controller device node will be able to enumerate
all devices associated with a video card (or embedded system or SoC).
>From one device node, an app should be able to discover all video, alsa,
dvb, and framebuffer device nodes on a video card, find out about
entities on the card, and set up the reconfigurable connections between
entities on the card. One should be able to discover subdevices on
cards like IR controllers.
The RFC before the mini-summit at the 2009 LPC is here:
http://lwn.net/Articles/352623/
The V4L media controller entity discover mechanism won't completely
solve the general discovery problem for IR. It will be one way to
discover IR devices associated with V4L supported peripherals. I assume
discovering USB IR-only devices by USB Id is not a problem. That leaves
serial port, parallel port and sound jack connected devices as the
difficult ones to "discover".
Regards,
Andy
> Christoph
> --
Andy Walls
> 1. Do we agree that a lirc (-style) kernel-user interface is needed at
> least?
Yes. Honestly, I'm just waiting on lirc_dev for the IR devices I work
with. With that I can get those new devices supported for both IR Rx
and Tx right now. I was holding off building a lirc_v4l module to see
if lirc_dev makes it in kernel.
However, because of the desire by V4L supporters wanting IR to just work
for remotes bundled with video capture cards, I have already added:
1. cx23885-input.c support with RC-5, and soon NEC support, in kernel.
2. new configurations for ir-kbd-i2c.c, due to IR hardware on some cx18
and ivtv supported cards.
So at least IR Rx works for the cheap bundled remote. I still think
input subsystem will never be able to rpovide a feature complete
interface though. I don't mind putting enough work in for the "Just
works" part with the bundled remote with -input, but not more.
> 2. Is there any problem with lirc kernel-user interface?
Here's my list
1. Unused transmit mode defines/enums. It's not a big deal really, but
I had a hard time figuring out the differences between CODE, MODE2,
PULSE since some are not well documented and some of those are not even
used for Tx.
2. The LIRC ioctls() wanting to change one parameter at a time will
cause me some thought/work. It would be better, I think, if LIRC would
do a get/set of all the parameters in one go.
That's what I do internally here:
http://linuxtv.org/hg/v4l-dvb/file/e0cd9a337600/linux/include/media/v4l2-subdev.h#l283
http://linuxtv.org/hg/v4l-dvb/file/e0cd9a337600/linux/drivers/media/video/cx23885/cx23888-ir.c#l746
http://linuxtv.org/hg/v4l-dvb/file/e0cd9a337600/linux/drivers/media/video/cx23885/cx23885-input.c#l269
The idea is that you set up the IR hardware infrequently and spend most
of the time letting it run. I'd have to think, if setting up the
hardware one parameter at a time may have it operating in a strange
mode, until the sequence of configuration ioctl() is complete.
I was planning on a lirc_v4l module aggregating all the lirc_dev ioctl
requests somehow to possibly avoid that potential problem.
Maybe an additional ioctl() from LIRC userspace and lirc_dev saying it
was done with the current IR device configuration sequence would be
another way to mitigate the problem for me.
> If the answer for #1 is "yes" and for #2 is "no" then perhaps we merge
> the Jarod's lirc patches (at least the core) so at least the
> non-controversial part is done?
>
> Doing so doesn't block improving input layer IR interface, does it?
It never has AFAICT.
A current related problem is that i2c based devices can only be bound to
only one of ir-kbd-i2c *or* lirc_i2c *or* lirc_zilog at any one time.
Currently it is somewhat up to the bridge driver which binding is
preferred. Discussion about this for the pvrusb2 module had the biggest
email churn IIRC.
This will be a general problem to fix for all the V4L-DVB drivers where
both LIRC and input can handle the device. A reasonable default
assumption *may* be that the user who bothers to configure LIRC wants
LIRC to override handling by input. That's a detail though...
Regards,
Andy
Ray Lee
>> If decoding can *only* be sanely handled in user-space, that's one
>> thing. If it can be handled in kernel, then that would be better.
>
> Why does the address space in which decoding is performed make the
> decoding process better or worse? The in kernel infrastructre and
> restrictions add constraints to a decoding implementation. Userspace is
> much more flexible.
In which case I look forward to seeing your patches to move
drivers/hid/ to userspace. Please cc: me so I can enjoy the ensuing
festival.
Jarod Wilson
> On Nov 29, 2009, at 12:27 PM, Krzysztof Halasa <k...@pm.waw.pl> wrote:
>
>> 1. Do we agree that a lirc (-style) kernel-user interface is needed at
>> least?
>>
>> 2. Is there any problem with lirc kernel-user interface?
>>
>> If the answer for #1 is "yes" and for #2 is "no" then perhaps we merge
>> the Jarod's lirc patches (at least the core) so at least the
>> non-controversial part is done?
>
>
> Isn't the meat of Jarod's patch the lirc interface?
Patch 1 was the lirc interface, 2 and 3 are individual device drivers that use it.
/me has some catching up to do on this thread after being partially detached from the computer over the holiday weekend here in the US...
--
Jarod Wilson
ja...@wilsonet.com
Artur Skawina
> On Sun, Nov 29, 2009 at 3:35 PM, Andy Walls <awa...@radix.net> wrote:
>>> If decoding can *only* be sanely handled in user-space, that's one
>>> thing. If it can be handled in kernel, then that would be better.
>> Why does the address space in which decoding is performed make the
>> decoding process better or worse? The in kernel infrastructre and
>> restrictions add constraints to a decoding implementation. Userspace is
>> much more flexible.
>
> In which case I look forward to seeing your patches to move
> drivers/hid/ to userspace. Please cc: me so I can enjoy the ensuing
> festival.
Umm, this thread is really about several independent issues
- Event delivery
There's an existing input system that works, there's no need to
reinvent the wheel; all remote events (usually key presses, but
there are also wheels/touchpads/joysticks/etc, which don't necessarily
map to buttons) should eventually arrive through it. Whether there's a
userspace component somewhere on the receiver->/dev/input path doesn't
change anything.
- Acquisition
If it isn't interrupt-driven it should to be in userspace. ADC falls
into this category, but also various bitbanging approaches and probably
also many serial port (ab)uses where the decoding isn't trivial.
(Receivers that require accurate timestamps could be one exception)
- Decoding
There is "decoding" and there is "translation". With hw receivers
(such as usb ir/rf dongles and HID devices mentioned above) you often
only need to translate or map events sent by the hw to the correct input
event and that's it. This can easily be done in-kernel (modulo complex
remote/key mappings, maybe).
Decoding analog input (even if it's only timing) is a different story.
Would you want to worry about somebody with an IR transmitter (think
phone/pda/laptop, but it could also be a modded remote) crashing your
machine, just because the in-kernel decoder didn't handle some weird
data? Or somebody leaving a small device around, which over time lead to
OOM, cause the kernel decoder kept leaking memory?
The bandwidth requirements for a remote are minimal, say <=20 events/s,
and the max latency in the 100ms range would still be ok, so two, or six,
context switches per key pressed shouldn't be a problem.
- Configuration
This isn't actually as simple as it looks at first. If you want to support
multiple remotes (and you do), complex mappings (eg one->many or sequence->one),
multiple modes etc then going through a userspace mapper is probably better.
I looked briefly at Jon's configfs i/f and it seems it could handle the
multiple-physical-remotes-with-one-receiver-and-multiple-independent-devices
case, but being able to grab the receiver, process the data in userspace and
reinject it back would still be needed for some setups.
artur
Mauro Carvalho Chehab
Alan Cox wrote:
> Does it really make sense to put big chunks of protocol decoding crap for
> an interface which runs at about 1 character per second on a good day
> into the kernel ? Does it really make sense ot move 50K of code from user
> context to kernel context where it must meet strict security
> requirements, be extensively audited and cannot be paged. For embedded
> users will also have to be highly modular so no unused bits are loaded.
The same logic would apply to mouse, keyboards and serial consoles.
It is possible to move everything to userspace.
However, there are some reassons for they to be in kernelspace:
- you may need them during boot time;
- they are mandatory to allow the users interaction;
- you need low latency.
The same arguments apply to IR, especially on embedded devices: some devices,
like TVs, Set Top TV boxes and IPTV Set Top Boxes have IR as their primary
input device.
Also, as changing a digital TV or an IP TV channel requires to discard the current
MPEG stream and getting a newer one, and it requires a large time until you'll
be able to output something to the user, one of the needs is to handle IR keystrokes
(especially channel up/down) as fast as possible, to try to minimize the discomfort
of changing a channel.
Using an approach where you'll send a raw event to userspace, process there and return
back to kernel will increase the latency and can only be done after when loading
the SYSV runlevel stuff.
On the other hand, we already have IR decoding in-kernel. Most of the code are
at:
drivers/media/common/ir-functions.c
But there are also some other decoders at bttv, saa7134 and cx88 drivers.
In the case of drivers/media stuff, there common case is that the drivers have
support for both space/pulse decoding and in-hardware decoding. On both cases,
the scancode is converted to a keystroke via evdev. IMHO, we shouldn't really
consider dropping those decoders from kernel.
Cheers,
Mauro.
Mauro Carvalho Chehab
> Hi Jon,
>
> on 27 Nov 09 at 12:49, Jon Smirl wrote:
> [...]
>> Christoph, take what you know from all of the years of working on LIRC
>> and design the perfect in-kernel system. This is the big chance to
>> redesign IR support and get rid of any past mistakes. Incorporate any
>> useful chunks of code and knowledge from the existing LIRC into the
>> new design. Drop legacy APIs, get rid of daemons, etc. You can do this
>> redesign in parallel with existing LIRC. Everyone can continue using
>> the existing code while the new scheme is being built. Think of it as
>> LIRC 2.0. You can lead this design effort, you're the most experience
>> developer in the IR area.
>
> This is a very difficult thing for me to do. I must admit that I'm very
> biased.
> Because lircd is the only userspace application that uses the LIRC kernel
> interface, we never had any problems changing the interface when needed.
> I can't say there's much legacy stuff inside. I'm quite happy with the
> interface.
It makes sense currently, but, once added at kernel, you won't be able
to change it again, without huge efforts. So, if the interface has any
trouble, we need to correct it before adding at the kernel. You should
remember that a kernel driver shouldn't be bound to an specific userspace
application. So, the same kernel interface should work with all lircd's
starting from the version where the interface was added. In other words,
it should be possible to use let's say a 5 year-old lirc with a brand
new kernel.
Also, some non lirc applications may arise, using the same kernel interface.
So, the API stability needs to be kept.
> The other thing is that I can't really move the decoder from userspace to
> kernel because there are way too many userspace drivers that do require a
> userspace decoder. LIRC also is running on FreeBSD, MacOS and even Cygwin.
> So letting the userspace drivers take advantage of a potential Linux in-
> kernel decoder is not an option for me either.
You can take advantage of a in-kernel decoder. Instead of receiving raw
pulse/space, you'll be receiving keystrokes (or scancodes).
Probably, it doesn't make sense to port every single IR protocol decoder
to kernel. We need there support for the protocols that come with the IR shipped
with the devices (I think that currently we have RC5, RC4, NEC and pulse-distance),
and the most used procolos at the universal IR's (RC5 may be enough?).
>> Take advantage of this window to make a
>> design that is fully integrated with Linux - put IR on equal footing
>> with the keyboard and mouse as it should be.
>
> That's a question that I have not answered for myself concludingly.
> Is a remote control really on exactly the same level as a keyboard or
> mouse?
On some devices like STB and TV sets (most of modern LCD/Plasma TV's run Linux),
they are at the same level. I'd say that the same applies to PC's that
the user has dedicated to work as an MCE.
Mauro Carvalho Chehab
> On Sun, 2009-11-29 at 09:49 -0800, Ray Lee wrote:
>> On Sun, Nov 29, 2009 at 9:28 AM, Maxim Levitsky <maximl...@gmail.com> wrote:
>>> This has zero advantages besides good developer feeling that "My system
>>> has one less daemon..."
>> Surely it's clear that having an unnecessary daemon is introducing
>> another point of failure?
>
> A failure in a userspace IR daemon is worst case loss of IR
> functionality.
>
> A failure in kernel space can oops or panic the machine.
If IR is the only interface between the user and the system (like in a TV
or a Set Top Box), both will give you the same practical result: the system
will be broken, if you got a crash at the IR driver.
> Userspace is much more flexible.
Why? The flexibility about the same on both kernelspace and userspace,
except for the boot time.
A kernelspace input device driver can start working since boot time.
On the other hand, an userspace device driver will be available only
after mounting the filesystems and starting the deamons
(e. g. after running inittab).
So, you cannot catch a key that would be affecting the boot
(for example to ask the kernel to run a different runlevel or entering
on some administrative mode).
After the boot, and providing that the kernel has the proper
API's, a pure userspace driver can behave just like a kernelspace
driver and vice-versa. The only difference may be in terms of device
transfer rate (not relevant for input devices) and latency.
Cheers,
Mauro.
Mauro Carvalho Chehab
> On Fri, Nov 27, 2009 at 2:45 AM, Christoph Bartelmus
> <chri...@bartelmus.de> wrote:
>> 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?
>
> Take advantage of the fact that we don't have a twenty year old legacy
> API already in the kernel. Design an IR API that uses current kernel
> systems. Christoph, ignore the code I wrote and make a design proposal
> that addresses these goals...
>
> 1) Unified input in Linux using evdev. IR is on equal footing with
> mouse and keyboard.
This makes sense to me. Yet, I think that, on some specific cases, we'll
need a raw interface.
> 2) plug and play for basic systems - you only need an external app for scripting
Yes.
> 3) No special tools - use mkdir, echo, cat, shell scripts to build maps
I don't think this is relevant. As we already have ioctls for building maps, and
while all in-kernel drivers can handle scancodes with up to 32 bits, I don't see
any reason to use anything different than what's currently available.
> 4) Use of modern Linux features like sysfs, configfs and udev.
sysfs/udev is a need for hot-plugging. I wouldn't use configfs for it. There aren't
many places using it and afaik some distros are not compiling their kernels with
configfs enabled. Also, as we have already ioctl's for keycode maps, I think
we shouldn't be migrating to controlfs.
> 5) Direct multi-app support - no daemon
For multi-app support usage like your example (e. g. different IR keys mapped into
the same evdev keycode and sent to different applications), I think we should need
a daemon for handling it.
> 6) Hide timing data from user as much as possible.
I agree. Porting the IRQ/gpio pollings to userspace on a system with a high workload
may mean that the keycode will be badly interpreted.
Mauro Carvalho Chehab
> Hi Mauro,
>
> I just don't want to change a working interface just because it could be
> also implemented in a different way, but having no other visible advantage
> than using more recent kernel features.
I agree. The main reasons to review the interface is:
1) to avoid any overlaps (if are there any) with the evdev interface;
2) to have it stable enough to be used, without changes, for a long
time.
>> I haven't seen such limitations on his proposal. We currently have in-kernel
>> decoders for NEC, pulse-distance, RC4 protocols, and some variants. If
>> non-RC5 decoders are missing, we need for sure to add them.
>
> That was not my point. If you point a NEC remote at the Igor USB device,
> you won't be able to use a NEC decoder because the device will swallow
> half of the bits. LIRC won't care unless the resulting scancodes are
> identical.
If the difference is just the bits order, and assuming that we use a standard
NEC decoder, a (kernel) driver will simply provide a different scancode for
that device, and the keymap table will be different, but it will still work
(an can still be plug and play).
In this specific case, we can opt to simply don't add any special hack for
Igor USB at the driver, but to leting the userspace tool to invert the bits
order when loading the keymap for that device.
>> Providing that we agree on what we'll do, I don't see why not
>> adding it on staging for 2.6.33 and targeting to have
>> everything done for 2.6.34 or 2.6.35.
>
> The problem that I see here is just that even when we have very talented
> people working on this, that put together all resources, we won't be able
> to cover all the corner cases with all the different receivers and remote
> control protocols out there. It will still require lots of fine-tuning
> which was done in LIRC over the years.
True, but even if we want to merge lirc drivers "as-is", the drivers will
still need changes, due to kernel CodingStyle, due to the usage of some API's
that may be deprecated, due to some breakage with non-Intel architectures, due
to some bugs that kernel hackers may discover, etc.
Also, there will be the needs for integrating with V4L/DVB code that may
also require some changes.
So, the drivers will still be different than what you currently have
and they may still need some fine-tuning after the merge.
Cheers,
Mauro
Andy Walls
> Andy Walls wrote:
> > On Sun, 2009-11-29 at 09:49 -0800, Ray Lee wrote:
> >> On Sun, Nov 29, 2009 at 9:28 AM, Maxim Levitsky <maximl...@gmail.com> wrote:
> >>> This has zero advantages besides good developer feeling that "My system
> >>> has one less daemon..."
> >> Surely it's clear that having an unnecessary daemon is introducing
> >> another point of failure?
> >
> > A failure in a userspace IR daemon is worst case loss of IR
> > functionality.
> >
> > A failure in kernel space can oops or panic the machine.
>
> If IR is the only interface between the user and the system (like in a TV
> or a Set Top Box), both will give you the same practical result: the system
> will be broken, if you got a crash at the IR driver.
Yes, true. I had forgotten about the embedded space.
Nonetheless I'd still rather debug a problem with a dead process in
userspace than an oops or panic (not that an end user cares) and avoid
the risk of filesystem corruption.
> Userspace is much more flexible.
>
> Why? The flexibility about the same on both kernelspace and userspace,
> except for the boot time.
I suppose my best answer to that is question back to you: Why does udev
run in userspace versus a kernel thread?
My personal thoughts on why user space is more flexible:
1. You have all of *NIX available to you to use as tools to achieve your
requirements.
2. You are not constrained to use C.
3. You can link in libraries with functions that are not available in
the kernel. (udev has libudev IIRC to handle complexities)
4. Reading a configuration file or other file from the filesystem is
trivial - file access from usespace is easy.
5. You don't have to be concerned about the running context (am I
allowed to sleep here or not?).
> A kernelspace input device driver can start working since boot time.
> On the other hand, an userspace device driver will be available only
> after mounting the filesystems and starting the deamons
> (e. g. after running inittab).
>
> So, you cannot catch a key that would be affecting the boot
> (for example to ask the kernel to run a different runlevel or entering
> on some administrative mode).
Right. That's another requirement that makes sense, if we're talking
about systems that don't have any other keyboard handy to the user.
So are we optimizing for the embedded/STB and HTPC with no keyboard use
case, or the desktop or HTPC with a keyboard for maintencance?
Regards,
Andy
Mauro Carvalho Chehab
> On Mon, 2009-11-30 at 09:56 -0200, Mauro Carvalho Chehab wrote:
>> Andy Walls wrote:
>>> On Sun, 2009-11-29 at 09:49 -0800, Ray Lee wrote:
>>>> On Sun, Nov 29, 2009 at 9:28 AM, Maxim Levitsky <maximl...@gmail.com> wrote:
>>>>> This has zero advantages besides good developer feeling that "My system
>>>>> has one less daemon..."
>>>> Surely it's clear that having an unnecessary daemon is introducing
>>>> another point of failure?
>>> A failure in a userspace IR daemon is worst case loss of IR
>>> functionality.
>>>
>>> A failure in kernel space can oops or panic the machine.
>> If IR is the only interface between the user and the system (like in a TV
>> or a Set Top Box), both will give you the same practical result: the system
>> will be broken, if you got a crash at the IR driver.
>
> Yes, true. I had forgotten about the embedded space.
>
> Nonetheless I'd still rather debug a problem with a dead process in
> userspace than an oops or panic (not that an end user cares) and avoid
> the risk of filesystem corruption.
>
>> Userspace is much more flexible.
>>
>> Why? The flexibility about the same on both kernelspace and userspace,
>> except for the boot time.
>
> I suppose my best answer to that is question back to you: Why does udev
> run in userspace versus a kernel thread?
udev relies on a kernel implementation: sysfs.
> My personal thoughts on why user space is more flexible:
>
> 1. You have all of *NIX available to you to use as tools to achieve your
> requirements.
>
> 2. You are not constrained to use C.
>
> 3. You can link in libraries with functions that are not available in
> the kernel. (udev has libudev IIRC to handle complexities)
>
> 4. Reading a configuration file or other file from the filesystem is
> trivial - file access from usespace is easy.
>
> 5. You don't have to be concerned about the running context (am I
> allowed to sleep here or not?).
You can do all the above steps with the proper API, just like udev does
with sysfs API.
After the boot, a device can open the raw API, disabling any in-kernel
decoding/handling and handle IR directly. Alternatively, an udev rule
can load a different keymap based on some config written on a file.
So, you won't loose anything by having an in-kernel driver or decoder.
>> A kernelspace input device driver can start working since boot time.
>> On the other hand, an userspace device driver will be available only
>> after mounting the filesystems and starting the deamons
>> (e. g. after running inittab).
>>
>> So, you cannot catch a key that would be affecting the boot
>> (for example to ask the kernel to run a different runlevel or entering
>> on some administrative mode).
>
> Right. That's another requirement that makes sense, if we're talking
> about systems that don't have any other keyboard handy to the user.
>
> So are we optimizing for the embedded/STB and HTPC with no keyboard use
> case, or the desktop or HTPC with a keyboard for maintencance?
If we remove the in-kernel decoders/evdev handlers, you'l limit the usecase,
where if you keep them in kernel, both ways can be used.
Cheers,
Mauro.
Jon Smirl
> I suppose my best answer to that is question back to you: Why does udev
> run in userspace versus a kernel thread?
Because udev is a scripting system. I've always said that the
scripting piece of IR belongs in user space. IR scripting should be
optional, none of the systems I work on need it.
This is the event flow being built...
device timing data
-- send timing data to user space
-- do protocol decode (40K code)
-- send decoded data back to kernel
other devices that decode in HW add events here
-- send decoded data to user space
-- map to keys (30K code)
-- send keys back to kernel
apps listen for keys
-- send keys back to user space
-- user space apps act on key (possibly run scripts)
I'd like to see...
device timing data
-- user space can inject timing data from user space drivers
do protocol decode (40K code)
other devices that decode in HW add events here
-- user space can inject decoded data from user space drivers
map to keys (30K code)
apps listen for keys
-- send keys back to user space
-- user space apps act on key (possibly run scripts)
>
> My personal thoughts on why user space is more flexible:
>
> 1. You have all of *NIX available to you to use as tools to achieve your
> requirements.
>
> 2. You are not constrained to use C.
>
> 3. You can link in libraries with functions that are not available in
> the kernel. �(udev has libudev IIRC to handle complexities)
>
> 4. Reading a configuration file or other file from the filesystem is
> trivial - file access from usespace is easy.
>
> 5. You don't have to be concerned about the running context (am I
> allowed to sleep here or not?).
>
>
>
>
>
>
>> A kernelspace input device driver can start working since boot time.
>> On the other hand, an userspace device driver will be available only
>> after mounting the filesystems and starting the deamons
>> (e. g. after running inittab).
>>
>> So, you cannot catch a key that would be affecting the boot
>> (for example to ask the kernel to run a different runlevel or entering
>> on some administrative mode).
>
> Right. �That's another requirement that makes sense, if we're talking
> about systems that don't have any other keyboard handy to the user.
>
> So are we optimizing for the embedded/STB and HTPC with no keyboard use
> case, or the desktop or HTPC with a keyboard for maintencance?
>
>
> Regards,
> Andy
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majo...@vger.kernel.org
> More majordomo info at �http://vger.kernel.org/majordomo-info.html
>
--
Jon Smirl
jons...@gmail.com
Maxim Levitsky
6. You can modify userspace driver easily to cope with all weird setups.
Like you know that there are remotes that send whole packet of data that
consist of many numbers that are also displayed on the LCD of the
remote.
Otherwise you will have to go through same fight for every minor thing
you like to add to kernel...
7. You don't have an ABI constraints, your userspace program can read a
configuration file in any format you wish.
I for example was thinking about putting all lirc config files into an
sqllite database, and pulling them out when specific remote is detected.
>
>
>
>
>
>
> > A kernelspace input device driver can start working since boot time.
> > On the other hand, an userspace device driver will be available only
> > after mounting the filesystems and starting the deamons
> > (e. g. after running inittab).
> >
> > So, you cannot catch a key that would be affecting the boot
> > (for example to ask the kernel to run a different runlevel or entering
> > on some administrative mode).
>
> Right. That's another requirement that makes sense, if we're talking
> about systems that don't have any other keyboard handy to the user.
>
> So are we optimizing for the embedded/STB and HTPC with no keyboard use
> case, or the desktop or HTPC with a keyboard for maintencance?
>
>
> Regards,
> Andy
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
Jon Smirl
Linux is not a microkernel it is a monolithic kernel.
http://en.wikipedia.org/wiki/Microkernel
If you want to push all of the device drivers to user space go run a
microkernel. Even the X server has finally come around to getting rid
of their cross platform OS in user space model and begun the switch to
kernel drivers. That transition is going to take ten years to
complete.
Once things get into the kernel they become far harder to change.
Stop for a minute and think about designing the best IR system for
Linux and forget about making a cross platform solution. IR is an
input device, it should be integrated into the Linux input subsystem.
You may not like the designs I have proposed, but running IR in user
space and injecting a keystroke at the end of the process is not
integrating it into the input subsystem.
>
>
>>
>>
>>
>>
>>
>>
>> > A kernelspace input device driver can start working since boot time.
>> > On the other hand, an userspace device driver will be available only
>> > after mounting the filesystems and starting the deamons
>> > (e. g. after running inittab).
>> >
>> > So, you cannot catch a key that would be affecting the boot
>> > (for example to ask the kernel to run a different runlevel or entering
>> > on some administrative mode).
>>
>> Right. �That's another requirement that makes sense, if we're talking
>> about systems that don't have any other keyboard handy to the user.
>>
>> So are we optimizing for the embedded/STB and HTPC with no keyboard use
>> case, or the desktop or HTPC with a keyboard for maintencance?
>>
>>
>> Regards,
>> Andy
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> the body of a message to majo...@vger.kernel.org
>> More majordomo info at �http://vger.kernel.org/majordomo-info.html
>
>
>
--
Jon Smirl
jons...@gmail.com
Maxim Levitsky
The above is trolling.
Maybe it will come as a surprise to you, but I am quite big supporter of
in-kernel code.
For example I don't quite like that alsa doesn't do mixing and
re-sampling in kernel.
These days pulseaudio works quite well, but it still sucks in some sense
sometimes.
I know about dmix/dsnoop, etc, these are nice, but still I would be
happy if kernel did that critical for both performance and latency thing
in kernel.
Some time ago an idea to move kernel VT support in userspace surfaced,
and I was against it too.
However, following established concept in philosophy, extremes are
equally bad.
Both pushing everything out of kernel, and shoving everything in is
equally bad.
So I am not blindly saying that, 'Everything belongs to kernel!'
or 'Lets put everything out, its more stable that way!, Moore law will
take care of performance...'
Instead I consider the pros and cons of both solutions, picking the best
one.
In that particular case I was even happy to see your kernel patches at
first glance, but then, after deep review I found that in-kernel
approach will create only problems, won't eliminate userspace decoding,
and solve only one problem, that is give good feeling about 'one less
daemon in system'.
> Once things get into the kernel they become far harder to change.
> Stop for a minute and think about designing the best IR system for
> Linux and forget about making a cross platform solution. IR is an
> input device, it should be integrated into the Linux input subsystem.
> You may not like the designs I have proposed, but running IR in user
> space and injecting a keystroke at the end of the process is not
> integrating it into the input subsystem.
Yes it is, like it or not.
Best regards,
Maxim Levitsky
>
>
> >
> >
> >>
> >>
> >>
> >>
> >>
> >>
> >> > A kernelspace input device driver can start working since boot time.
> >> > On the other hand, an userspace device driver will be available only
> >> > after mounting the filesystems and starting the deamons
> >> > (e. g. after running inittab).
> >> >
> >> > So, you cannot catch a key that would be affecting the boot
> >> > (for example to ask the kernel to run a different runlevel or entering
> >> > on some administrative mode).
> >>
> >> Right. That's another requirement that makes sense, if we're talking
> >> about systems that don't have any other keyboard handy to the user.
> >>
> >> So are we optimizing for the embedded/STB and HTPC with no keyboard use
> >> case, or the desktop or HTPC with a keyboard for maintencance?
> >>
> >>
> >> Regards,
> >> Andy
> >>
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> >> the body of a message to majo...@vger.kernel.org
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> >
> >
>
>
>
--
kevin granade
<mch...@redhat.com> wrote:
> After the boot, a device can open the raw API, disabling any in-kernel
> decoding/handling and handle IR directly. Alternatively, an udev rule
> can load a different keymap based on some config written on a file.
This idea of the in-kernel decoding being disabled when the raw API is
opened worries me. What guarantees that the following scenario will
not happen?
User uses apps which retrieve the decoded IR messages from the kernel.
User installs an app which decodes messages via the raw API (not lirc).
User's other applications no longer receive IR messages.
I know the assumption has been that "only lirc will use the raw API",
but this seems like a poor assumption for an API design to me.
A related question, what is an application developer who wishes to
decode the raw IR signal (for whatever reason) to do? Are they
*required* to implement full decoding and feed all the messages back
to the kernel so they don't break other applications?
For clarity, I'm not arguing for a particular approach, I'm not fully
able to follow the discussion on this issue, but this one issue
bothered me.
Thank you for your time,
Kevin
Mauro Carvalho Chehab
> Nonetheless I'd still rather debug a problem with a dead process in
> userspace than an oops or panic (not that an end user cares) and avoid
> the risk of filesystem corruption.
Considering my experience adding in-kernel support for IR's, I'd say that
in general, a driver does some things:
1) it polls or waits IRQ's for an IR event. On raw IR devices, the read value
means a mark or a space;
2) it counts the timings between each pulse, and pulse/space duration;
3) it runs a protocol decoding logic that, based on pulse/space duration, one
scancode is produced;
4) it does a table lookup to convert the scancode into the corresponding keycode;
5) it generates an evdev event.
Steps 2 and 3 happen only when the device doesn't have hardware decoding capabilities.
For devices with hardware decoding, the polling/IRQ process already retrieves a scancode.
Based on my experience, I can say that, from the above logic, the one
where you're more likely to generate an OOPS is at the first one,
where you need to do the proper memory barriers for example to avoid
unregistering an IR while you're in the middle of an IRQ or pull handling.
In the case of IRQ, you'll also need to take care to not sleep, since you're
in interrupt mode.
If you're outputing raw pulse/space to userspace (a lirc-like raw interface),
you'll still need to do steps (1) and (2) in kernel, and doing a logic close
to (5) to output an event to userspace.
So, the basic difference is that you won't run the decoder (3) nor do a table lookup (4).
The logic for (4) is trivial (a simple a table lookup). If you do a mistake
there, the bug will likely arise at the development time. Also, if you're not able
to write a proper code to get a value from a table, you shouldn't be trying
to write a driver anyway.
The logic for (3) is as simple as identifying the length of a pulse and the length of
the spaces. Depending on the length, it will produce a zero or one. Pure integer math.
The only risk of such logic is if you try to divide by zero. Except of that, this type
of code shouldn't cause any OOPS or panic.
Also, for (3) and (4), it is very easy to write it first on userspace (if you feel
more comfortable on doing so) and, after doing enough testing, add the same code to
kernelspace.
Cheers,
Mauro.
Mauro Carvalho Chehab
> On Mon, Nov 30, 2009 at 7:24 AM, Mauro Carvalho Chehab
> <mch...@redhat.com> wrote:
>
>> After the boot, a device can open the raw API, disabling any in-kernel
>> decoding/handling and handle IR directly. Alternatively, an udev rule
>> can load a different keymap based on some config written on a file.
>
> This idea of the in-kernel decoding being disabled when the raw API is
> opened worries me. What guarantees that the following scenario will
> not happen?
>
> User uses apps which retrieve the decoded IR messages from the kernel.
> User installs an app which decodes messages via the raw API (not lirc).
> User's other applications no longer receive IR messages.
>
> I know the assumption has been that "only lirc will use the raw API",
> but this seems like a poor assumption for an API design to me.
All those questions are theoretical, as we haven't a raw API code
already merged in kernel. So, this is just my understanding on how
this should work.
If the user wants to use the raw interface, it is because the in-kernel
decoding is not appropriate for his usage (at least while such application
is opened). So, not disabling the evdev output seems senseless.
Btw, this is the same behavior that happens when some application directly
opens an evdev interface, instead of letting it to be redirected to stdin.
> A related question, what is an application developer who wishes to
> decode the raw IR signal (for whatever reason) to do? Are they
> *required* to implement full decoding and feed all the messages back
> to the kernel so they don't break other applications?
If such application won't do it, the IR will stop working, while the
application is in use.
Lennart Sorensen
> The only thing this buys for the user is remote/products bundles that
> work out of the box. That can only be a solution for the 80% case.
>
> I don't hear users crying out "Please integrate IR with the input
> system". I do hear users say "I want my remote to work", and "How can I
> make my remote work?". Users are not specifically asking for this
> integration of IR and the input system - a technical nuance. If such a
> tecnical desire-ment drives excessive rework, I doubt anyone will care
> enough about IR to follow through to make a complete system.
Please integrate it so I can stop having issues with the lirc moduels
when going to a new kernel version.
> What does "equal footing" mean as an incentive anyway? The opportunity
> to reimplement *everything* that exists for IR already over again in
> kernel-space for the sake of developer technical desires? That's just a
> lot of work for "not invented here" syndrome. IR transceivers are
> arguably superior to keyboards and mice anyway because they can transmit
> data too.
I have no idea. I am sure you guys will come up with a great interface.
I just use lirc with my mythtv box.
--
Len Sorensen