[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100327055654.GA18689@elf.ucw.cz>
Date: Sat, 27 Mar 2010 06:56:54 +0100
From: Pavel Machek <pavel@....cz>
To: Mauro Carvalho Chehab <mchehab@...hat.com>,
Jon Smirl <jonsmirl@...il.com>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Krzysztof Halasa <khc@...waw.pl>,
hermann pitton <hermann-pitton@...or.de>,
Christoph Bartelmus <lirc@...telmus.de>, awalls@...ix.net,
j@...nau.net, jarod@...hat.com, jarod@...sonet.com,
kraxel@...hat.com, linux-input@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
superm1@...ntu.com
Subject: Re: [RFC] What are the goals for the architecture of an in-kernel
IR system?
Hi!
> > Anyway, one simple way to avoid
> > resetting the hardware for every new parameter change would be to use a timer
> > for reset. This way, an userspace application or script that is touching on
> > several parameters would just send the complete RX init sequence and
> > after some dozens of milliseconds, the hardware will load the new parameters.
>
> And I do not think that sounds like a good interface.
Yep. Having artifical delay is ugly, racy and error prone. (If
application is swapped out, you'll set the hardware to middle state,
anyway).
Better solution would be to have "COMMIT" command that actually does
the setup, or interface that allows all parameters at once...
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists