On Fri, Jul 02, 2010 at 03:02:07PM +0200, Henrik Rydberg wrote: > Hi Chase, > [...] > >> The rangeToMask allocates memory in the inner event loop... > >> > >> The whole mapping construction seems a bit backwards. If unused valuators > >> are > >> never referenced, there is no need to do all those extra copies. As a side > >> effect, > >> > >> *EventsM(events, pDev, type, key_code, mask, num_valuators, all_valuators); > >> > >> could be implemented like > >> > >> *EventsM(events, pDev, type, key_code, mask, num_valuators + > >> first_valuator, > >> valuators - first_valuator); > > > > My thought was to keep the API simple and in line with previous > > functions. Thus, the bitmask and the valuators arrays start at the 0th > > valuator index of the device. > > > > To get around doing any copying when *Events functions are called, we > > could either duplicate the code so that we don't send *Events calls > > through *EventsM, or we could change the *EventsM valuators argument > > meaning: instead of being an array starting at the 0th valuator, it > > would start at the first valid valuator in the bitmask. > > > > Though not as simple in theory, it's not that complicated, so I'll just > > change the meaning of the valuators argument and get rid of the copying. > > But it does complicate things a bit, doesn't it? Peter, how much is that > first_valuator actually used, i.e., different from zero? Perhaps one could > simply change the api higher up as well, and get rid of the problem > altogether. > Maybe this was implicit in Peter's response?
i think only evdev ever sets first_valuator to non-null and that caused a few bugs when it was introduced :) at least in the event generation state, the processing stage needs to cope with it for DeviceValuator events. Cheers, Peter > >> The bit mask is memory efficient, why not allocate in on the stack? It > >> would > >> certainly be a lot faster. > > > > Yeah, that makes more sense. I'll update the code. > > Good good. All in all, this is great work, and we are much farther down a > useful > route now than a couple of weeks ago. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
