> Regarding extending input interface - let's talk about what is missing. > You mentioned memory-mapped access, but I am not sure if it should be > implemented within current input structure or if it should be a > completely separate interface. If we implement it we should also make > sure we stabdardize the data stream and not simply dump raw device > data, as this would be a sep backwards. >From a data perspective, what is missing is the notion of a large collection of values of the same kind. The immediate usecase in mind is of course a pressure or intensity value, mapped onto a surface. The current (key, value) event model works in principle, but becomes increasingly inefficient with increasing collection size. A simple way of transporting a large collection where values change sparsely is via a memory-mapped multi-dimensional array. True, it is not given that such data needs to be incorporated into the current input structure, and it may be benficial not to do so; the memory map, be it real or device memory, serves as its own state and there is no need to keep any other state. However, it seems reasonable to inherit the input event semantics, since the data to transport is not new, there are only more data points of the same kind. Other possibilities exist, of course, such as using descriptors similar to HID, or a more elaborate sysfs tree, but it does not seem necessary. Therefore, what I propose initially is a model of an n-dimensional, memory-mapped array, specififed by a set of input event types. For example, to formulate a matrix of pressure values in the X-Y plane, all you need to specify are the three values (ABS_PRESSURE, ABS_X, ABS_Y), listed in the preferred loop order. The value ranges are given by the absinfo structs, which also gives the dimension of the array. The above does not need to be implemented using struct input_dev, it could be its own machinery, possibly using uio. Since no event drivers such as evdev are needed, no bus structure is needed either. The files could simply be exported in a manner quite similar to sysfs nodes. Thanks, Henrik -- 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
