Dmitry Torokhov wrote:
> On Thu, Nov 26, 2009 at 03:49:13PM -0200, Mauro Carvalho Chehab wrote:
>> Dmitry,
>> While lirc is basically a series of input drivers, considering that they 
>> have lots
>> in common with the input drivers at V4L/DVB and that we'll need to work on
>> some glue to merge both, do you mind if I add the lirc drivers at 
>> drivers/staging from
>> my trees? 
> Mauro,
> I would not mind if you will be pushing it to staging, however I am not
> sure we have an agreement on what exactly the interface that we will be
> using. I would hate to get something in that will need to be reworked
> again.

I understand your concerns.

IMHO, we should be really careful with API's when migrating from staging to the
right place, but I'm not that much concerned with staging. We already have 
drivers there with bad behaviors and even with some API's there that will go to 

For example there's a V4L2 driver there (staging/go7007) that has their own 
API to handle compressed streams. I won't ack moving it from staging while
it has their own private extensions for something that are part of V4L2 API.

Also, staging drivers without progress for a few kernel cycles will be moved to 
so I don't see much sense of denying a driver to go there.

Anyway, I'll add it there only when you feel comfortable about that and send us 
your ack.


>From what I heard on the comments, I think we have already a consensus of some 
        1) all IR's should implement the standard evdev interface;
        2) IR's with raw interfaces will implement a raw pulse/space IR 
The proposal is to use lirc API interface for raw pulse/code TX and RX.

Do you think we'll need to better detail the IR raw interface API before 
the patches for staging? If so, what level of details do you want?

To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to
More majordomo info at

Reply via email to