I promised a reply today, so here's a quick go at it... Things are a
bit busy right now with some massive changes taking place in my daily
work, the kids getting back into school, hockey and soccer starting up
for my son, gymnastics for my daughter, etc... :)
On Sep 5, 2009, at 8:07 PM, Maxim Levitsky wrote:
> What I think is that, in long term, lirc_dev support should get away
> from asking drivers to define their fops.
Simpler drivers would certainly be a good thing...
> Even a tiny wrapper over fops will be enough.
> Also, I think that set_use_inc, and set_use_dec are misnamed.
Never was a big fan of those names myself, but they're just names,
easy enough to change.
> I think that proper layout for driver operations might be:
> /* prepare hardware for work - replaces .set_use_inc */
> int init(struct lirc_driver *drv)
> /* shutdown hardware - replaces .set_use_dec */
> void deinit(struct lirc_driver *drv)
> /* receive buffer of data - replaces .add_to_buf */
> int receive (struct lirc_driver *drv, struct lirc_buffer *buf)
> /* transmit a packet*/
> int transmit (struct lirc_driver *drv, int* packet, int len)
> /* flash a led */
> int flash_led(struct lirc_driver *drv, int flags);
> /* set range for for RX carrier. (-1,-1 means use wide receiver)*/
> int set_rx_carrier(struct lirc_driver *drv,
> int low, int high);
> /* set TX carrier*/
> int set_tx_carrier(struct lirc_driver *drv, int carrier);
> /* duty cycle settings - why we need RX duty cycle?*/
> int set_rx_duty_cycle(struct lirc_driver *drv, int duty_cycle);
> int set_tx_duty_cycle(struct lirc_driver *drv, int duty_cycle);
> /* set recording mode*/
> int set_rx_mode(struct lirc_driver *drv, int mode);
> int set_tx_mode(struct lirc_driver *drv, int mode);
> All 'settings' functions return 0 on success, and last set value is
> stored in lirc_driver structure. Thus no need for _get functions.
> Also, on resume from low power state (ram/disk) lirc core calls these
> functions, to set up device again.
> Absence of functions indicate that device doesn't support this or that
> Will be glad to hear your comments.
Sounds sane. Just a simple matter of code. And not breaking people's
existing setups. ;)
>> Note that for lirc_imon, lirc_mceusb and lirc_streamzap, I'm thinking
>> more and more that I'd like to add input device support to all of
>> Their default mode of operation with no lirc client attached would
>> be to
>> send the keycodes for their default remotes via the input
>> subsystem, but
>> once an lirc client attaches, they'd send their data via the lirc
>> interface. This way, stock remotes work out-of-the-box with no
>> configuration, but you've still got the ability to use lircd for
>> decoding everything, which I think is particularly important for
>> receivers that support umpteen different IR protocols and remotes.
> Nice idea, but I suspect you will need a RC6 decoding in kernel to
> decode default remote for lirc_mceusb?
Ah, right, yes.
This sort of goes hand in hand with what's apparently being discussed
on the linux-input list (crap, I probably need to go hop on *another*
mailing list...). It also goes along with some discussion on the linux-
media list, about adding assorted shared decoding for remotes shipped
with tv tuner cards to have them Just Work out of the box. Not sure if
those two are connected, or if this is just such a hot topic right
now, its being discussed all over...
I'm personally okay with in-kernel decoding of the common protocols,
as long as there's still a way to let lircd do it instead. If that
initially means supporting both an input device and an lirc device at
the same time, that seems like a reasonable compromise to me. Things
could/would behave much like the imon driver, sending input events
when no lirc clients are attached, and when they are, they send (or
receive) data via their lirc device. In the long run, maybe this idea
of sending raw IR codes out via input devices gets fleshed out and
replaces the need for an lirc device, as David mentioned, but there
isn't any fully functional code for that yet (as I understand it), and
we already have a working solution here that a LOT of people depend on