Andreas Beck writes: > > On the TODO list is the job of having a stateful key/value hash > > that is funneled through the gii event stream, such that it can provide > > things like full-length device information. Retreiving values from > > this hash is an addition to the API that we are planning anyway -- > > setting/back-propagating values in the hash would not be that much more > > of an effort. > > Yep. Agree > > > If we defined a standard set of keys that most filters would support, > > we would have a way to do runtime alteration of filter-specific behavior > > like sifting for origins, etc, without having to add any more API > > functions to LibGII itself. > > Apropos origins - did noone read my bug report about the > "querying-for-inputs" problem ? > > I'd like to have confirmed that it exists and is not only a quirk of my > program or my strange setup before diving into the code and fixing it. > > CU, Andy
I think I got it. The problem is that the xdevinfo is static in the xlib input source. So when you open more than one x target, they uncorrectly share the same xdevinfo structure, hence origin. It's also true for all targets. Eric.
