On 08/01/2018 05:13 AM, Bastien Nocera wrote: > On Tue, 2018-07-31 at 18:57 +0000, Roderick.Colenbrander@xxxxxxxx > wrote: >> > <snip> >> For me the question is what is the difference between a 'pressure >> sensitive button' and an 'axis'? At a high-level they are similar, >> but >> does one need extra APIs for best support? > > 3 things I think: > - you don't have a concept of "not pressed" for an axis. Sure it has a > resting/default position, but you have to encode that press boolean > somehow That's certainly a difference. I looked a bit at how different hardware is handling this. I think DS3 always reports non-zero analog values even if 'not pressed'. Wooting currently reports analog values for pressed keys. To be exact it maintains a small buffer containing the scancode of "pressed keys" and their analog value. They have an adjustable threshold in hardware at what "depth" to trigger a digital key press. Maybe there will be hardware as well, which doesn't generate the digital click, but expects software to "fake digital press". Maybe we need to allow that flexibility somehow in the API or at least a way to adjust threshold long-term for drivers wanting to offer that. (Through a flag?) > - axis wouldn't be able to support something like the GameCube trigger, > which has a click when pushed down fully. I don't know how this is > encoded, and whether this is just a higher value for the axis, or > actually sends that data out. Interesting wasn't aware of that. Something to explore how this is the case. > I'm guessing you plan on sending both the analog and digital value at > the same time to user-space, if so, we really need a way to match > corresponding analog buttons with their digital counterparts, otherwise > user-space will have difficulty handling devices with a mix of digital- > only and analog-capable buttons. My current thought in the proposal was to tie the EV_KEY and EV_PSR together by using the same codes (and maybe a special addition PSR specific range long-term). Though not the biggest fan. Another way is to offer in a "struct psrinfo" struct the value of an associated EV_KEY. This is I think among the trickier parts to solve. (Actually we kind of have the same issue already for regular axes. Some of these have a button press already. Left/right trigger is an axes, but also offers a digital press and the same for left/right sticks. There only few codes there, so I guess it is fine.) > Does that make sense? > > If you want to decant the API a bit quicker, it would be great if you > also ported, say, the PS3/PS4 joypad driver, and had a patch to evtest > available. Then user-space developers would be able to test the API > before it lands fully in the kernel. > We will write an initial implementation for evdev and at least 1 driver supporting it probably hid-sony for DS3 or uinput. Thanks, Roderick -- 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
