On Tue, Jul 31, 2018 at 08:49:08PM +0000, Roderick.Colenbrander@xxxxxxxx wrote: > 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. I *think* what David meant is some sort of multiplexing where the key itself would be just one value and the actual events refer to state of that value. the mt protocol gives you ABS_MT_SLOT and then a bunch of axes you can send for that slot. Moving the EV_PSR to something similar would likely be using PSR_SLOT like the slot and then using other axes/identifiers to send specific information. The biggest advantage here is that you can add information later that you haven't thought of now. A made-up event sequence would be something like: EV_PSR PSR_SLOT 1 EV_PSR PSR_KEY_MAP KEY_A EV_PSR PSR_PRESSURE 80 SYN_REPORT EV_PSR PSR_PRESSURE 85 EV_PSR PSR_LOGICALLY_DOWN 1 EV_KEY KEY_A 1 SYN_REPORT EV_PSR PSR_PRESSURE 82 SYN_REPORT EV_PSR PSR_PRESSURE 80 EV_PSR PSR_LOGICALLY_DOWN 0 EV_KEY KEY_A 0 SYN_REPORT .. maybe some terminating event equivalent to TRACKING_ID -1 PSR_KEY_MAP would be the "this key maps to EV_KEY KEY_A" event which can now tie those together. Pressure is obvious. It's fairly easy to add things like EV_PSR/PSR_LOGICALLY_DOWN for binary click emulation. Together with the PSR_KEY_MAP event this would allow for filtering of EV_KEY events provided they come in the same frame. Free backwards compatibility, what's not to like! I'm not sure whether we need an event for sequence tracking. the states aren't necessarily sequence based like a touch is but they're pretty close. It certainly relies on the driver knowing what the neutral state is and emulating that. That aside, I'd strongly advocate **not** using struct absinfo but making new ones even if it looks exactly the same. Anything using EV_PSR needs new code anyway, might as well not accidentally limit yourself to something you can't independently extend. Anyway, there are a few other things like: is the key map static for the slot? If so you can make it available through your ioctl and simply rely on the client to know this. Instead of slots you can then use magic identifiers (i.e. PSR_SLOT 13 is always that thing that maps to KEY_A when pressed). Not sure that's a useful solution. It probably requires more storage and handling client-side but I'll throw it out there anyway) Is pressure the only thing that matters? If no, then you almost have to go with this approach or something similar. I suspect by the time we get this ready someone comes up with a hover-sensitve and pressure-sensitive button :) Cheers, Peter > > 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
