On Sun, May 02, 2010 at 02:13:31PM +0200, Daniel Mack wrote: > Hi Dmitry, > > On Tue, Apr 20, 2010 at 11:29:29PM -0700, Dmitry Torokhov wrote: > > On Mon, Apr 19, 2010 at 08:06:06PM +0200, Daniel Mack wrote: > > ... > > > > As we're on it - I'm quite unhappy with the allocation of the buttons > > > in the snd-usb-caiaq driver. I merely abuse valid values from enums > > > that are defined in input.h and leave it to the userspace to map things > > > back to their original meaning. Is there any change to introduce a more > > > dynamic model which describes buttons by given strings rather than > > > enums? Such an interface could also well be be used for ABS entities, > > > and that would also solve the problem I currently have. Userspace should > > > then have a way to query an entity's name for these special cases. > > > > Unfortunately input layer is not well-suited for device-specific data. I > > understand that some devices are pretty domain-specific and do not fit > > into standard model of event describing intended useage for everyone. I > > am open to sugggestions/RFC-style patches. > > Well, I can live with the fact that enum members are abused so that > their name doesn't have to do much with the actual meaning, even though > that's not optimal. However, in this specific case, the problem is > that I have more axis than available element types, so I'm stuck. But > instead of heacking my way around it using other transport methods down > to userspace, we might also clean up legacy-style limitations once for > good. > > > > > Another issue is that ABS data is pretty large, it would be nice if we > > > > moved from this data being always present ininput device structure to > > > > having drivers allocate it when needed. > > > > > > Ah, the struct has ABS_MAX as length for a fix-sized array, I see. Hmm. > > > Then we shouldn't make that bigger for such reasons, I agree. > > > > > > > Alocating data dynamically was on my todo list forever. Maybe someone > > will beat me to it *wink, wink* > > Hmm, maybe I could also help with that. Could you outline where this > should go? I guess a linked list is not very suitable as it doesn't > allow instant access of specific members. So we need a fixed-size bitmap > to indicate active members at least? I was just thinking about having drivers taht emit absolute events allocate abs data (value, min, max, resolution) separately from allocating a device (or maybe have additional input_abs_device_alloc helper). Someting very simple. > > Would that also make sense for all other information than ABS? > The rest are much smaller so I am not that worried, at least for now. -- 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
