On 14 Feb 2007 03:45:00 +0100, Christoph Bartelmus <[EMAIL PROTECTED]> wrote:
> Hi!
>
> Jon Smirl "[EMAIL PROTECTED]" wrote:
> > LIRC folks, there is an on-going discussion about possible future
> > designs for IR support in the kernel. What's your take on how to do
> > this?
>
> Pass all events to userspace and let lircd do the mapping/decoding.
>
> In case of the atiusb device there are currently 17 different remotes
> known. Handling this in userspace is a lot easier.
> It is of course possible to do the mapping in kernel space and it seems
> like it makes configuration for the user easier, but from my experience
> users simply don't want that their remotes act like a normal keyboard.
> From time to time your will see requests on the LIRC mailing list like
> "Help, when I press buttons on my remote, some weird symbols appear in
> my terminal. How do I disable this?"
> If users want that their remote works like a keyboard this is still
> possible using uinput. Actually you can use kbdd [1] to do exactly this
> already.
> If there was enough interest I could easily integrate this in lircd
> without having to use an additional program and having to do additional
> configuration. lircd could convert remote signals automatically to
> uinput events using the remote's button name. E.g. a button called "1"
> could generate a KEY_1 event or "MUTE" could generate a KEY_MUTE event.
evdev doesn't just handle keyboards. It is a general purpose event
interface for getting UI events out of the kernel. The idea is that
there is a standardized message structure and a set of common IDs.
Each remote would cause a new device to be created in /dev/input, for
example event4 or event5. Applications then read events from these
device nodes in the standardized format.
include/linux/input.h
struct input_event {
struct timeval time;
__u16 type;
__u16 code;
__s32 value;
};
Keyboard works this way and so does the mouse. There are also drivers
for a lot miscellaneous input devices. Everything isn't mapped to the
keyboard. For example, your mouse events aren't showing up on your
keyboard since they occur on a different event node. IR remotes would
get an event node for each remote seen.
An example: pulseaudio needs two input modules:
Volume Control
# module-mmkbd-evdev
# module-lirc
If lirc were to report events over evdev pulseaudio would only need
the evdev module.
Using evdev to do event reporting can be done with either a user or
kernel space LIRC implementation. The uinput driver allows user space
programs to generate evdev events. evdev would allow LIRC to get rid
of the client library.
Example programs using evdev:
http://www.frogmouth.net/hid-doco/c537.html
> If you are still not convinced that lircd should handle mapping/
> decoding, then look at a device like the Streamzap remote or the Windows
> Media Center remote. These devices do not decode the IR signals
> themselves but just deliver the signal waveform to the host PC. The
> signal waveform is decoded by lircd. I know dozens of different IR
> protocols with countless variations. Trying to decode these protocols in
> kernel space is out of question for me. It would mean putting most parts
> of lircd into kernel space.
These are a lot of good arguments for keeping lircd.
How about getting your existing kernel drivers merged into mainline?
> I know that there are currently some TV card IR drivers that decode RC5
> in kernel space. These drivers prevent the user from choosing a
> different remote control which uses a different protocol.
This is part of the problem, remote controls are not being handled
uniformly in the kernel.
There are those USB ATI radio based remotes too.
> Additionally the Windows Media Center can be used as IR blaster. The
> input layer cannot be used to make use of this feature.
Vojtech, is this some way to send events the other direction through evdev?
> Now look at the IR devices that are handled by LIRC completely in
> userspace. For example you can connect an IR receiver to your soundcard
> and let lircd use ALSA to receive the signals. Or look at the receivers
> that connect to the serial port and use standard 1200 8N1 communication
> through the kernel's serial port driver. There's no way for these
> drivers to use the kernel's input system other than using uinput.
>
> That's why I suggest using the LIRC driver system like it is with lircd
> being the uniform interface for applications. If the user wants his
> remote to act like a keyboard he could configure lircd to enable this
> feature independent of how the hardware is working internally.
>
> The only drawback of this approach I can see is that for some devices
> there is additional overhead as the input events have to be routed
> through lircd although the drivers could generate the input events
> directly. But the advantages of the current LIRC approach outweigh this
> drawback by far IMHO.
>
> Christoph
>
> 1: http://www.handhelds.org/moin/moin.cgi/kbdd
>
--
Jon Smirl
[EMAIL PROTECTED]
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
