Hi Terry, On Thu, Jan 27, 2011 at 11:58:38AM -0800, Terry Lambert wrote: > Hi; > > I'm looking for some guidance from Linux/input people... > > I've looked through the archives, and around the net a bit, and I > haven't been able to find anything to capture events from an arbitrary > set of inputs, and then replay them back to software attached to those > inputs. I do not believe there is anything production - quality but I remember seeing programs proxying the input from one box to another over the network. > > This would be useful for: > > o Regression testing user space algorithms > o Training software for gesture recognition > o Tuning drivers for new hardware to correct self-censor undesirable events > o Probably lots of other things I haven't thought of > > The multiple event sources requirement comes from using things like > keyboard modifier keys to change mouse button behaviours. The most > obvious example is probably option-click on Apple hardware with a one > button mouse. > > The basic problems with just opening up /dev/eventX, /dev/eventY, ... > and listening/injecting are: > > o If a piece of software grabs the input, I don't get events Right, grab means exclusive access. > o If I grab the input, the software I'm testing doesn't get events *nod* > o If neither of us grabs the input, filters apply As they should. > o If the input is grabbed by someone, you can't inject events Again, grab is exclusive access > o It won't work if the event consuming software lives in kernel space That I am not sure, injected events do get distributed to all handlers/filters. > > The basic problems with using the filter mechanism are: > > o Filters are applied after grabs, so if it's grabbed the filter is not invoked > (I read the thread introducing filters; this makes sense) > o You can only have one filter at a time > (there might already be one) You should be able to have several filters. > > Has anyone tried to solve this problem before? Any suggestions? The canonical way for augmenting input stream in user space would be with a program that open/grabs one or several event devices, does processing and loops resulting events back into kernel via uinput (again creating one or many input devices). Because you create 2nd set of input devices you avoiding all issues with grabs/exclusive assess with consumers of your data. Hope this helps. -- Dmitry -- 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
