On Sat, Aug 15, 2009 at 06:02:27AM +0300, Maxim Levitsky wrote:
On Sun, 2009-08-09 at 11:56 +0200, david@xxxxxxxxxxx wrote:
Here's a new patch set which should replace all the patches currently in the
-mm tree for the winbond cir driver. The new series incorporate feedback from
Bjorn Helgaas (convert the driver from ACPI to PNP) and Randy Dunlap (Kconfig
fixes).
The IR decoding can still be improved but the driver works for in daily use
decoding RC6 commands, so I believe it is ready to go upstream.
Hi.
Hi,
As I understand, this hardware returns sampled IR signal, so it can be
used with any remote, right?
Yes.
Then why not to implement lirc driver?
That's a fair question, but I'm afraid you're putting the cart before
the horse.
The question is not why anyone would want to write an in-kernel driver
but rather why anyone would want to write an out-of-kernel driver.
There have been repeated attempts to get LIRC merged with the kernel,
and the feedback has been pretty consistent - make it part of the input
subsystem.
I have written the driver for the input system and it limits the driver
somewhat. I am working on extending the input system to accomodate IR
drivers (see the discussion of EV_IR on the linux-input list).
As an example, the input system already has a quite extensive set of
additional functions to deal with force-feedback hardware (mostly
additional ioctl's, see include/linux/input.h). I want the input system
to grow similar extensions for IR hardware which would then allow IR
drivers to be written as input drivers with their full functionality
exposed to user-space.
Feel free to help me out in implementing that API, and porting LIRC
drivers, and all the benefits of in-kernel drivers will flow from that
work.
To be more specific, the things that are on my radar right now are:
o IR TX - I believe an IOCTL which will take an array of signed integers
symbolizing IR on/off timings together with parameters for IR
carrier modulation is the way to go and to let userspace deal
with the generation of those integers (for a number of
reasons).
o IR RX - We need to expose the full functionality of hardware with
multiple receivers to userspace. Microsoft's current CIR specs
mandate that IR hardware that includes transmitters must
include both a long-distance, narrow-band receiver for common
use and a short-distance, wide-band receiver for learning
purposes. Expect future hardware to meet those demands...
o Hardware differences -
The lircd daemon currently has a "-H" parameter to specify the
driver to use. To me, that is a dead giveaway for an
inconsistent kernel <-> userspace API. We can do better, given
the proper HW flags from the input layer, userspace should
adapt automatically. Some hardware, say
drivers/media/dvb/ttpci/budget-ci.c (where you'll find my name
in the git logs) only support passing decoded RC5 events. Some
hardware (like the lirc mceusb(2) driver) passes the timing
for the IR signals and supports any remotely sane IR protocol.
The WPCD376I has even a bit more capabilities like
wake-from-poweroff, two receivers and up to four transmitters
with the capability to detect which transmitters are connected
and which ones are not.
The challenge at this point is not in writing drivers for the
hardware, it is designing an extension to the input layer that
can sanely deal with the diversity.
Anyhow, do check the linux-input list for my EV_IR patches, they are the
first step in that direction (and they're based on the API proposal by
Jon Smirl posted at the end of last year). Raw signalling information
for wonky remotes is part of that proposal (though the patches are not
fully fleshed out yet).
This driver as I understand is a driver for single remote shipped with
the notebook.
It's a driver for a winbond chipset shipped with many Intel desktop
"media" motherboards (DP35DP, DG33TL, DX388T, DX488T2, DP455G, DG45ID
and DG45FC are the ones I'm aware of).
I have recently wrote a lirc driver for my receiver, a lirc driver. Now
I can use all my remotes.
So can I. But for a easy-to-use and consistent user interface, some
changes are needed to the input layer.
And no, I don't need any software support for that. LIRC happily
forwards all events via uinput to kernel, so I use it a an ordinary
keyboard.
I know LIRC and what it can do, look in the CVS logs and the LIRC
mailing list archives and I think you'll find my name there.
Regards,
David Härdeman
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
