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? Would that also make sense for all other information than ABS? Daniel -- 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
