On 07/30/2018 11:52 PM, David Herrmann wrote: > Hi > > (+CC Dmitry, Jiri, Peter, Benjamin) > > On Tue, Jul 31, 2018 at 1:48 AM <Roderick.Colenbrander@xxxxxxxx> wrote: >> Hi all, >> >> I would like to share a proposal to extend evdev with support for >> pressure sensitive "analog" buttons. It is a feature common on gaming >> peripherals (arcade sticks, gamepads, wii guitar) as well now on analog >> keyboards such as Wooting One / Two keyboards on which every button is >> both analog and digital (so ~100 analog keys). >> >> These devices are difficult to support using the existing evdev API. The >> problem is the EV_KEY event type was meant for digital keys, whereas the >> EV_ABS could be used for this purpose except that it has reached its >> axes limit due to the EVIOCGABS/SABS limitation of 0x40. >> >> The proposal is to add a new event type "EV_PSR" to evdev to describe >> pressure sensitive keys. Keys reported to this mechanism can report >> analog values. Often devices also report a digital value for the same >> button, so EV_PSR analog keys can have a matching digital EV_KEY. For >> this reason, we suggest to share key codes. (This is up for debate of >> course to tie both together like this.) >> >> Pressure sensitive keys, have similarities with regular absolute axes as >> they have min/max values and probably fuzz makes sense as well. It could >> be said we should extend ABS like David Herrmann proposed in his ABS2 >> proposal a while ago and remove the EVIOCGABS/SABS limitations. >> >> This is an initial proposal to address limitations in evdev to improve >> device support in existing drivers such as hid-sony, hid-betopff, >> psxpad-spi, hid-wii and probably others as well as new devices such as >> Wooting keyboards >> >> Thanks, >> Roderick Colenbrander > > I like it. Reporting pressure information of keys is currently a huge > hassle and this would simplify it a lot. > > The question I see is whether to extend evdev with EV_PSR (or EV_ABS2 > for that matter), or to switch to multitouch'ish reports, which simply > combine multiple input-events. What do you mean with multitouch'ish reports? Reporting something other than input_event or something through the fd? I guess you are looking at a way to not send too many reports through evdev? It can be quite noisy many modern game devices have sample rates close to 1kHz, so a lot of events events just for digital buttons and some analog sticks alone already. > Furthermore, the current > 'input_device->absinfo' array is already quite big. Adding another one > with an entry for *every* possible key will probably not work out. So > the implementation will probably not be straightforward. Yeah storage of the array needs consideration. I was considering an absinfo-like struct, which also contains 'code'. This can be handy for kernel side (e.g. storing the struct in some kind of list). It can also be handy if we want userspace to query multiple values through a single ioctl, though not a big fan of 'inout' parameters if they can be avoided. > > Thanks > David -- 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
