Ahoi!
On Thu, Apr 11, 2019 at 11:24:30AM -0700, Sean O'Brien wrote:
> Hi Benjamin and Peter,
>
> Thanks for your detailed replies. I'm glad you found it interesting :)
>
> On Wed, Apr 10, 2019 at 5:47 PM Peter Hutterer <peter.hutterer@xxxxxxxxx> wrote:
> >
> > Hey!
> >
> > I just have a few notes on top of what Benjamin said.
> >
> > On Wed, Apr 10, 2019 at 06:51:45PM +0200, Benjamin Tissoires wrote:
> > > Hi Sean,
> > >
> > > On Wed, Apr 10, 2019 at 1:29 AM Sean O'Brien <seobrien@xxxxxxxxxxxx> wrote:
> > > >
> > > > Hello,
> > > >
> > > > I'm currently working on designing an interface for controlling "forcepads";
> > > > that is, touchpads with force sensors and haptic actuators. Below is my
> > > > proposal for the protocol at both the userspace and HID interfaces. I would
> > > > appreciate any feedback you might have.
> > >
> > > Thanks a lot for starting this discussion. This is indeed an
> > > interesting topic, and I had a lengthy chat with Peter this morning :)
> > >
> > > First, I'd like to get a small clarification.
> > > In the proposal, you are making reference to both the HID side (so the
> > > hardware protocol) and the kernel side (the client protocol).
> > > I read it that you are trying to build two things:
> > > - the HID design proposal, aimed at hardware makers
> > > - the kernel behavior on how to use it
> > >
> > > If that is the case, I am glad that you can put some pressure to force
> > > a sensible protocol to hardware makers :)
> > >
> > > Though, I think we should make a clear separation between the 2. We
> > > need to think of it as a whole, but the document should clearly put
> > > the boundaries IMO.
> > >
>
> You are correct - there are two levels here and I'll try to make the separation
> more clear in future versions.
>
> > > >
> > > > Thank you,
> > > >
> > > > Sean O'Brien
> > > > Chromium OS Touch/Input Team
> > > >
> > > > Background
> > > > ==========
> > > >
> > > > There are multiple independent projects to develop a touchpad with force sensors
> > > > and haptic actuators, instead of a traditional button. These “forcepads” have
> > > > several advantages and potential uses; they allow clicking across the entire
> > > > touchpad surface, adjusting the force requirement for clicks, haptic feedback
> > > > initiated by UI, etc.
> > > >
> > > > Objective
> > > > =========
> > > >
> > > > Develop a standard protocol to allow userspace applications to communicate with
> > > > forcepads, and minimize duplicated code and effort.
> > > >
> > > > Requirements:
> > > > 1. Support UI-initiated haptic feedback.
> > > > 2. Allow userspace to control when button press and button release haptic
> > > > effects are triggered. (Useful when detecting a false click, changing force
> > > > thresholds, or sending context-dependent effects)
> > > > 3. Allow a backward-compatible mode where the forcepad produces button press and
> > > > button release effects autonomously.
> > > > 4. Reveal force sensor readings to userspace applications.
> > > >
> > > > Proposal
> > > > ========
> > > >
> > > > I propose standardized forcepad support in the linux kernel at both the HID and
> > > > userspace interface.
> > > >
> > > > Userspace Interface
> > > > -------------------
> > > >
> > > > Multitouch
> > > > ..........
> > > >
> > > > The linux kernel has a well defined protocol [0] for multitouch devices,
> > > > including touchpads. The protocol defines a field called ABS_MT_PRESSURE as a
> > > > measure of the pressure applied by a contact. Unfortunately, it is not used
> > > > that way in practice- instead it is generally used as an approximate measure of
> > > > contact area. I will distinguish these concepts by calling them “true force” and
> > > > “traditional pressure”.
> > >
> > > Well, yes and now. It depends on the underlying technology.
> > > For capacitive sensors, "traditional pressure" if reported through
> > > ABS_MT_PRESSURE is the surface contact area. This is a rough
> > > equivalent to a pressure, assuming we all have somehow flexible
> > > fingers, and roughly the same shape. But for resistive touchscreens,
> > > IIRC we have already access to the "true force".
> > >
> > > IIRC, when both ABS_MT_MAJOR and ABS_MT_MINOR are reported, libinput
> > > ignores ABS_MT_PRESSURE. So in a sense, there is no need to add a new
> > > ABS event, this one works quite well.
> >
> > just as an extra note here: the kernel doc for ABS_MT_PRESSURE says "The
> > pressure, in arbitrary units, on the contact area", so that's what we do in
> > libinput (and the old synaptics driver) at least. We have arbitrary
> > thresholds but they are by device or device series. So *how* the pressure
> > was generated by the hardware itself is already meaningless because all it
> > gives us is some continuous data without useful reference points.
> > IOW, using ABS_MT_PRESSURE will work just fine.
> >
> > And we can't just assume "if resolution is set, units are $foo" because
> > nothing written in the last decade or so will assume that. Some extra flag
> > is needed, like INPUT_PROP_FORCEPAD.
> >
>
> Great, I won't worry about the distinction then, except to say forcepads must
> always use force and define units.
>
> > > >
> > > > Instead of using ABS_MT_PRESSURE to report the “traditional pressure,” forcepads
> > > > would send “true force” values in this field. For each contact, this field would
> > > > report the estimated force applied by that contact.
> > > >
> > > > The resolution of ABS_MT_PRESSURE should also be defined and reported, so that
> > >
> > > Please define here what units the protocol expects. And please make it
> > > international (g/m2, N/m2 or whatever). Though Newtons might be
> > > difficult to grasp for people.
>
> I was actually thinking Newtons (or grams), instead of g/m2 or N/m2. The sensors
> are more directly measuring force rather than pressure. The value could be
> converted to pressure based on the contact area, but this raises the question of
> how to report when force is applied to the pressure with no fingers, e.g.
> pressing with an eraser or some object that doesn't trigger the capacitive
> sensors. If we us N or g, this value can be reported in ABS_PRESSURE directly.
> Otherwise I'm not sure how to convert to pressure units.
I think N are just fine here. The evdev API is what it is and given the
circumstances I don't think don't need to attempt to be scientifically exact
here.
> > > > userspace consumers can translate to force units. By defining the resolution, we
> > > > also differentiate it from how it is used to report “traditional pressure”,
> > > > where it has no resolution. Userspace consumers will be able to use this to
> > > > detect that this is a forcepad, and treat the pressure field accordingly.
> > >
> > > I tend to disagree. It is best in that case to explicitly mark the
> > > forcepad as such by adding a new INPUT_PROP. INPUT_PROP_FORCEPAD would
> > > be nice.
> > >
> > > The reason is you don't know for sure that the reported unit is
> > > correct for the existing devices. If you want this to actually matter,
> > > then you can enforce the unit to be correct for a certified device,
> > > and then only export INPUT_PROP_FORCEPAD for those devices (thinking
> > > at the Win8 certification blob for multitouch screens/touchpads).
> > >
> > > Note that defining what an INPUT_PROP_FORCEPAD is would be nice. For
> > > example does the user controlled haptic feedback be a requirement.
> > >
> > > I would suggested:
> > > - can differentiate between at least 5 fingers
> > > - correct resolution for the X/Y (units and value)
> > > - report correct force per touch, and correct units for them
> > > - follows the MT protocol type B
> > >
> > > So for hardware vendors, we would require to follow the MS spec for
> > > input devices in Win8 and Win8.1, and in addition support the Simple
> > > haptic controller HID table, and report correct units for the
> > > pressure.
> > >
>
> Agreed, adding a new INPUT_PROP is much cleaner, and acts as a convenient label
> for describing where this protocol should be followed.
>
> > > >
> > > > ABS_PRESSURE may be optionally reported as the total force applied to the
> > > > forcepad.
> > > >
> > > > The device/driver shouldn’t detect button clicks, this is left to the userspace
> > > > gesture library. Accordingly, the driver should not sent BTN_* events to
> > > > userspace in normal operating mode. However it should still report the ability
> > > > to produce such events, for use in autonomous mode.
> > >
> > > For backward compatibility, and to be able to debug it properly, you
> > > should keep the BTN_* events emulated in all cases.
> > > The userspace can ignore the events it doesn't want this way, but you
> > > will be able to debug the btn emulations on your current session
> > > without having to kill your compositor.
> > > There shouldn't be much of a head over forwarding those events, as it
> > > will never come alone, and will always be with an other one at least
> > > (pressure being 0 or less).
> > >
> > > Also, not sending BTN_TOUCH and BTN_LEFT might give some headaches to
> > > legacy applications.
> > >
>
> This also makes the difference between host-controlled and autonomous mode
> smaller, so this sounds good to me.
>
> > > >
> > > > Haptic Control
> > > > ..............
> > > >
> > > > The force feedback protocol [1] should be used to request predefined effects.
> > >
> > > s/request/control/
> > >
> > > >
> > > > Typical use of the force feedback protocol requires loading effects to the
> > > > driver by describing the output waveform, and then requesting those effects
> > > > using an ID provided by the driver. We don’t want to describe the output
> > > > waveform explicitly, but instead use a set of predefined IDs for the desired
> > > > effect types. The device/driver would be responsible for having the effects
> > > > loaded and ready to respond to a request for the predefined IDs.
> > >
> > > Re-reading through this made my head a little bit clearer.
> > >
> > > I think I am starting to see what you are saying, but the proposal
> > > would need to be more precised here.
> > >
> > > >
> > > > The force feedback protocol will need to be extended to allow requests for
> > > > predefined IDs. This requires a new feedback effect type:
> > > >
> > > > /**
> > > > * struct ff_predefined_effect
> > > > * @level: strength of the effect
> > > > * @vendor: ID of the vendor who defined the effect
> > > > * @id: ID of the effect among those defined by the vendor
> > > > */
> > > > struct ff_predefined_effect {
> > > > __s16 level;
> > > > __u16 vendor;
> > > > __u16 id;
> > > > }
> > > >
> > > > Vendors can define specifications for the waveforms and assign them IDs. They
> > > > could then be requested using their vendor ID and the waveform ID, as defined in
> > > > the simple haptic HID protocol [2].
> > > >
> > > > To allow a standard way to trigger press and release effects, all forcepads
> > > > should support the WAVEFORM_PRESS and WAVEFORM_RELEASE through this interface.
> > > > Since the standard waveform id namespace doesn’t overlap with the vendor
> > > > waveform id namespace, the vendor id can be ignored for these waveforms.
> > >
> > > First of all, I think you should split the HID (device/firmware)
> > > requirements from how they are used in the kernel.
> > >
> > > IMO, it's fine to say that only touchpads exporting the "simple haptic
> > > HID protocol [2]" will be supported by this proposal.
> > >
>
> This is position I'd like to take, to discourage a proliferation of different
> protocols.
>
> > > And FWIW, the Microsoft Surface Dial already exposes this HID
> > > collection, and can be used to toy around the proposal (just saying).
> > >
> > > If you intend to be more generic, we should not refer to this HID
> > > collection but explain how things are going to be in shape in the
> > > kernel.
> > >
> > > That being said, there are a few additions/changes I'd like to see.
> > >
> > > The way the input_ff protocol works is:
> > > - userspace upload an effect through EVIOCSFF and stores it in an id
> > > - this effect is supposedly stored into the device itself
> > > - userspace can then play the effect whenever it wants by calling the
> > > id in an input_event written to the evdev node
> > > - eventually, userspace can remove the effect with EVIOCRMFF
> > >
> > > This doesn't entirely matches the simple haptic HID protocol.
> > >
> > > As I read the documentation, the simple haptic HID only defines a set
> > > of waveform types:
> > > WAVEFORM_NONE, WAVEFORM_STOP, WAVEFORM_CLICK,
> > > WAVEFORM_BUZZ_CONTINUOUS, WAVEFORM_RUMBLE_CONTINUOUS, WAVEFORM_PRESS,
> > > and WAVEFORM_RELEASE. It also defines a "vendor" range where vendors
> > > can put any waveform they see fit and define in their haptic device.
> > >
> > > So, I think that's why you want to augment the ff protocol by adding
> > > the struct ff_predefined_effect.
> > >
> > > After thinking more about that, you are correct, we can not express
> > > those "simple haptic HID" waveforms in the current ff protocol. But I
> > > think the new struct should be focused on HID, not vendors, and
> > > contains the whole effect settings. All the current struct ff_*_effect
> > > also have the period, the magnitude, the offset, etc...
> > >
> > > Re-reading through the HID HUTRR, I think we should add Intensity,
> > > Repeat Count, and Duration.
> > >
> > > So I would prefer to have a more generic ff_effect:
> > > struct ff_hid_effect {
> > > __u16 hid_usage;
> > > __s16 intensity;
> > > __u16 repeat_count;
> > > __u16 duration;
> > > }
> > >
> > > The id is already part of struct ff_effect, so this should allow us to
> > > "upload" a predefined hid effect.
> > >
> > > Note that as I read it, we do not want auto-triggered haptic feedback
> > > here. If we do, we would nee to add an other field to the
> > > ff_hid_effect struct.
> > >
> > >
> > > The next thing I'd like to get some clarifications is how these
> > > effects are used. As I read it, userspace "uploads" the effect, and
> > > uses it, but the HID HUTRR doesn't say that the effects and parameters
> > > are stored in the device itself. It is for the auto triggered ones,
> > > but given that we want to opt for the manual trigger, we should store
> > > it ourselves.
> > >
>
> My understanding is that all the simple haptic effects are indeed stored in the
> device. Certain parameters (intensity, repeat_count, retrigger_period) are
> dynamic, but the list of available waveforms (WAVEFORM_PRESS etc.) and their
> associated durations are static properties of the device.
>
> In fact, I think we will want to add a mechanism for userspace to ask for a list
> of all available waveforms, instead of querying for each specific waveform it
> may be interested in.
Do we have a specific use-case for this? APIs that allow listing things
that are otherwise basically random are mostly useful for debugging tools
(where performance isn't usually an issue) but nothing else. If you are a
userspace process and I give you a list of WAVEFORM_PRESS, WAVEFORM_RELEASE,
0x1231113, 0x11aaab1123 and 0x112abff11, what will you do with that
information? if you have #defines for some of them (e.g. press, release) you
can query them directly. If not - does it matter what else I support?
As a library author, I can definitely say that an API that only allows "do
you have capability $FOO" is a lot simpler to support than "give me all
capabilities you know of".
> So we would add FF_SIMPLE to the features bitfield. If this feature is
> supported, userspace can use a new ioctl to find the supported simple effects:
>
> struct input_ff_request_simple {
> __u16 vendor_id;
> __u16 vendor_page;
> __u16 hid_usages[num_effects];
> __u16 durations[num_effects];
> }
>
> In this case vendor_id and vendor_page apply to all the waveforms in the vendor
> range.
>
> Then userspace can "upload" effects with:
>
> struct ff_hid_effect {
> __u16 hid_usage;
> __s16 intensity;
> __u16 repeat_count;
> __u16 retrigger_period;
> }
>
> > > So, the solution we came to this morning, while talking to Peter, was
> > > that the HID driver for a simple haptic HID device would allocate a
> > > virtual device memory to store the effects and the parameters.
> > >
> > > This way, we can:
> > > - upload effect WAVEFORM_RELEASE with its parameters in id 0 of the
> > > drvdata of the device
> > > - upload effect WAVEFORM_PRESS with its parameters in id 1 of the
> > > drvdata of the device
> > > - ...
> > > - upload effect WAVEFORM_VENDOR_ZZZ_ZZZ with its parameters in id N of
> > > the drvdata of the device -> userspace will use it while scrolling for
> > > instance
> > > - ...
> > >
> > > Then the kernel on BTN_LEFT press can automatically trigger the effect
> > > with id 1 and the one with id 0 on release in the case of the
> > > autonomous mode mentioned below.
> > >
> > > To solve the question of knowing which effect should be loaded in
> > > which slot, I think we should rely on a userspace helper (udev?).
> > > We definitively not want the kernel to keep a list of devices to
> > > effects matches, but having a udev database (hwdb and intrinsic?)
> > > would nicely solve the issue as we do not need to update the kernel
> > > for each new device coming in.
> > >
> > > From the kernel driver, we can populate the WAVEFORM_PRESS and
> > > WAVEFORM_RELEASE with some sensible parameters, but userspace should
> > > be allowed to override them.
> > >
> > > The advantage of having this virtual memory of device effects, is that
> > > each userspace implementation could use its own matching for effects.
> > > For example, libinput might want to say:
> > > - id 0 -> BTN_LEFT released
> > > - id 1 -> BTN_LEFT pressed
> > > - id 0x1000 -> scrolling up
> > > - id 0x1001 -> scrolling down
> > > - id 0x2042 -> hard press
> > >
> > > But chromeOS might use different ids and different meaning for them.
> > > The first 2 ids first should be reserved for the kernel button left
> > > emulation though.
> > >
> > > Note that given that the effect memory is 'virtual' in the driver, we
> > > can use any id and we are not limited to a few numbers of them.
> > >
> > > An other thing is that we do not need to require WAVEFORM_PRESS and
> > > WAVEFORM_RELEASE. If they are set in the haptic device, the kernel can
> > > set them for us, but if they are not, userspace can always decide to
> > > put one of the other waveforms in ids 0 and 1.
> > >
> > > We should mention that not defining these two waveforms will induce a
> > > state were no haptic feedback will be automatically loaded from the
> > > kernel though (userspace will have to do it).
>
> True, I guess I would say it's strongly encouraged to include WAVEFORM_PRESS and
> WAVEFORM_RELEASE for that reason.
>
> > >
> > > >
> > > > Autonomous mode
> > > > ---------------
> > > >
> > > > In order to facilitate an operating system which cannot handle force feedback,
> > > > the forcepad should start up in “autonomous mode”, meaning it acts as a normal
> > > > touchpad. This means it should perform the press and release haptic feedback
> > > > autonomously at predefined force thresholds, and send the appropriate BTN_*
> > > > events.
> > >
> > > I think that if we were to follow my idea of using effect ids 0 and 1
> > > for release/press, we should mention that the kernel will play the
> > > effects stored as these ids.
> > >
> > > >
> > > > After verifying that all of the required haptic effects are available through
> > > > the force feedback protocol, the OS can enable host-controlled mode. This could
> > > > be done by writing to a sysfs node “host_feedback_enabled”.
> > >
> > > You don't really want a sysfs file here. Because if the input part
> > > generating the haptic feedback crashes, or if you are VT switching and
> > > your evdev node gets revoked, you are left in a system without haptic
> > > feedback for clicks.
> >
> > Extra note here: compositors don't have write access to sysfs. some do, but
> > the default assumption is that they don't.
> >
> > > So, our idea was to use a new couple of ioctls, EVIOCFFTAKEMASTER and
> > > EVIOCFFRELEASEMASTER (or whatever is more politically admitted), which
> > > the kernel would ref count on each effect id.
> > >
> > > So, if the OS decides to take control over the press autonomous haptic
> > > feedback, it will emit the ioctl EVIOCFFTAKEMASTER with the effect id
> > > 1. If an other client also wants to control this id, it can also take
> > > the control, and the total count of clients controlling this effect id
> > > is now 2. If a BTN_LEFT is emitted by the device (or emulated by the
> > > kernel), the driver will check the refcount of the effect id, sees
> > > that there is at least one, and will not forward the haptic effect to
> > > the device.
> > > On the contrary, in this case, effect id 0 is not handled by
> > > userspace, and the kernel will control it when a BTN_LEFT release is
> > > emitted.
> > >
> > > Note that this ioctl will only have an impact on effect ids 0 and 1.
> >
> > hmm, I don't think there's a technical reason for that limitation, is there?
> > simply specifying it as "any effect ID that does not have a current master
> > will not get auto-played by the kernel". Simple enough and leaves the actual
> > usage more flexible.
> >
> > > The benefit of using an ioctl is that is the client closes the fd, or
> > > if the fd gets revoked, the kernel can decrement de usage count and
> > > eventually switch back to the autonomous mode described above.
> >
> > I'll add a shorter summary for the normal case, just to make it easier to
> > comprehend the whole thing:
> > - the kernel has default effects for ids 0/1
> > - some process (udev) uploads device-specific waveforms where needed, for ids
> > 0/1 and others if need be
> > - the kernel always sends BTN_LEFT when some hardcoded threshold is met
> > - when sending BTN_LEFT, the kernel plays id 0/1 for release/press
> > - if a process has the EVIOCFFTAKEMASTER for a given id, the kernel does not
> > play it and relies on that client to do so.
> >
> > This approach means:
> > - default behaviour is predictable and useful
> > - updating for devices is in userspace
> > - the entity controlling the click-buzz (e.g. libinput) doesn't need to be
> > aware of the device-specific waveforms
> > - VT-switch/compositor change/suspend/... (i.e. close(fd)) restores default
> > behaviour
> > - other processes can use the pad for haptic feedback without interfering or
> > having to care about whether the session supports forcepads for button
> > handling
> >
> > > > When the host enters suspend mode, the OS will not be able to respond quickly
> > > > enough to input from the touchpad to tell it to perform haptic feedback, making
> > > > the touchpad feel unresponsive. When the host suspends, the touchpad should
> > > > enter autonomous mode.
> > >
> > > This could be achieved in my proposal above by either closing the fd,
> > > or revoking it, so we would get this for free :)
> > >
> > > >
> > > > HID Interface
> > > > -------------
> > >
> > > So this is the part where we tell ODM what to do. Correct?
> > >
> > > >
> > > > Multitouch
> > > > ..........
> > > >
> > > > The HID API for multitouch reports is mostly unchanged except:
> > > >
> > > > 1. The tip pressure field [3] should be used to report “true force” instead of
> > > > “traditional pressure”. The physical unit type, exponent, and limits should
> > > > be reported in the report descriptor for the “true force” field [4].
> > >
> > > works for me
> > >
> > > > 2. The device will always report it’s button as being unpressed, except in
> > > > autonomous mode, when it will report the button state according to its
> > > > predefined force thresholds.
> >
> > fwiw, devices that report capabilities but never send those events are a
> > nightmare to deal with because it forces heuristics and guesswork in the
> > clients that can be wrong at any point. Filtering events because we pretend
> > to know better than the kernel driver is a lot easier.
> >
> > Cheers,
> > Peter
> >
> >
> > > I think I would prefer having a basic left button emulation that we
> > > can rely on when userspace doesn't know about forcepads.
> > > This would allow us to not have to emulate it in the kernel, but just
> > > forward the data as it comes in.
> > >
> > > Also, this would allow the driver to not have to drive the haptic
> > > feedback in the autonomous mode: we just set the auto trigger on
> > > BTN_LEFT usage, and done.
> > > (if we do not enforce the auto triggering, then the driver will also
> > > have to manually send the haptic events on BTN_LEFT 0/1).
> > >
>
> This all sounds good to me. However, I don't think I was entirely clear. When I
> said "autonomous mode", I meant more "device-controlled". So really there are
> three modes to think about:
>
> - Userspace-controlled: Some process has emited ioct EVIOCFFTAKEMASTER for ids
> 0/1. The device will emit BTN_LEFT at some hardcoded force threshold. The
> kernel will forward those events to userspace but will not play haptic
> effects.
> - Kernel-controlled: Nobody has taken control of ids 0/1 so the kernel will
> default to playing id 0/1 whenever BTN_LEFT changes.
> - Device-controlled: The auto trigger is set on the device, associated with
> BTN_LEFT.
>
> I want device-controlled mode because if the system suspends, I want the device
> to be able to respond with haptic effects for press and release quickly. So the
> kernel should set the auto trigger when suspending.
>
> However, there is a limitation of the HUTRR: only one waveform can be set as the
> auto trigger, so we would have to choose one waveform to be played for both
> press and release. Therefore, I would like to use kernel-controlled mode when
> the system is not suspended, so it can send the correct waveform.
We're blurring the HID vs evdev distinction and I'm not sure which one
you're discussion here but: from userspace, kernel vs device-controlled is
an implementation detail of the kernel. so is having only one auto-trigger,
just play the same one for press release when you must, and do the right
thing otherwise.
probably obvious and we all agree here, but let's state it out loud at least
once :)
Cheers,
Peter
> > > If we are giving requirements to ODM, I think we also need:
> > >
> > > 3. a specific application usage that tells us that the device is a forcepad.
> > > Ideally, I would love to extend the HUT, but we might consider saying
> > > that a forcepad, to be exposed as such, needs to expose a "Simple
> > > Haptic Controller" logical collection alongside the Touch Pad one.
> > >
> > > That's what the Surface dial is doing:
> > > - application collection: System Multi-Axis Controller
> > > - logical collection: Puck
> > > - logical collection: Simple Haptic Controller
> > > - logical collection: Durations List
> > > - logical collection: Waveforms List
> > > - endof application collection
> > >
> > > So this would make clear what a HID forcepad is.
>
> Sounds good.
>
> > >
> > > 4. a way to store in the HID device the pressure threshold the device
> > > is supposed to report the click.
> > > We can guess which threshold it is if the unit is correct, but I think
> > > I would rather have the device telling us this. Problem is, I can not
> > > find a good HID usage for that.
>
> Ah yes, I had thought about that a little too. Like you, I couldn't find a good
> HID usage. I'd appreciate any alternate suggestions for that.
>
> > >
> > > 5. If a device doesn't meet those criteria above, it will not get
> > > categorized as a FORCEPAD and will not get all the fancy FF effects
> > > from the OS.
> > >
> > > This last point is very important as this will prevent us to have to
> > > deal with quirky devices.
> > >
> > > Note that MS solved the issue by requiring ODM to actually test their
> > > devices, and then MS issues a blob in a vendor feature that is tested
> > > to enable or not the touchscreen / touchpad gestures.
> > >
> > > >
> > > >
> > > > Haptic control
> > > > ..............
> > > >
> > > > The simple haptic HID protocol [2] should be used.
> > >
> > > s/should/must/
> > >
> > > >
> > > > The following waveforms should be supported:
> > > >
> > > > | WAVEFORM_NONE | Implicit waveforms required by protocol |
> > > > | WAVEFORM_STOP | |
> > > > | ------------------------ | ------------------------------------------------- |
> > > > | WAVEFORM_PRESS | To be used in autonomous mode and host-controlled |
> > > > | WAVEFORM_RELEASE | mode to simulate button press and release. |
> > >
> > > I would not absolutely require those 2. If they are present, the
> > > kernel (driver) should set them as the default feedback (in the
> > > autonomous mode), but if they aren't, it's not a big deal, the
> > > userspace will have to quirk the device.
> > >
> > > > | ------------------------ | ------------------------------------------------- |
> > > > | Vendor-defined waveforms | Optional waveforms to be used in host-controlled |
> > > > | | mode, subject to vendor specification. |
> > >
> > > I think we should just say that the device is free to implement all
> > > the waveforms it wants as per HUTRR 63b.
>
> Fair enough, as long as at least one waveform is declared (as is required by
> HUTRR 63b) it can be designated as a forcepad. WAVEFORM_PRESS and
> WAVEFORM_RELEASE are recommended but not required.
>
> > >
> > > >
> > > > All waveforms will have an associated duration; continuous waveforms will not be
> > > > supported.
> > > >
> > > > Only manual triggering will be supported through this interface. Autonomous
> > > > triggering of waveforms is enabled by putting the device in autonomous mode.
> > >
> > > This part is ambiguous. The Auto triggering on the HUTRR 63b says that
> > > when the device emits a specific HID usage, it will also emit the
> > > matching haptic effect.
> > > While here, you want the kernel to driver the button press/release
> > > (unless I am reading it wrong).
> > >
> > > Also, I think you are mixing here the HID requirements and the
> > > exported kernel API. I think there is nothing wrong to comply with the
> > > HUTRR 63b. We can use the auto-trigger functionality in the autonomous
> > > mode described above. The point is that we do not want to export that
> > > to the userspace.
> > >
>
> Yes, you are right. We can achieve the various autonomous modes
> (kernel-controlled and device-controlled) through HUTRR 63b using manual and
> auto triggering respectively.
>
> > > >
> > > > Retriggering (queueing multiple triggers of the same waveform) is not supported.
> > >
> > > This will simplify the new struct_hid_effect, but I am not sure there
> > > is a point to prevent the haptic device of having that capability.
> > >
> > > >
> > > > If intensity modification for waveforms is supported by the device, the
> > > > intensity control should be included in the manual trigger output report. This
> > > > allows modification of the intensity on a per-waveform basis.
> > >
> > > yep
> > >
> > > So I think we should simply say that the haptic feedback needs to
> > > follow HUTRR 63b, with the following amendments:
> > > - continuous waveforms will be ignored by the host
> > > - Repeat Count will be ignored by the host
> > > - Auto mode trigger might get used for the autonomous mode described
> > > above, but can be optional
> > >
>
> I've been convinced that there's no harm in supporting retriggering, and that in
> fact we should encourage the use of auto trigger so the device can perfom
> effects when the system is suspended.
>
> Best regards,
> Sean
>
> > > >
> > > > Alternatives Considered
> > > > =======================
> > > >
> > > > Add a “true force” field to the multi-touch protocol
> > > > ----------------------------------------------------
> > > >
> > > > This allows us to send “traditional pressure” in addition to “true force”. It
> > > > also allows another possible protocol in addition to sending the force per
> > > > contact:
> > > >
> > > > * Sending overall force and center of force: Should be easier to calculate
> > > > depending on force sensor layout, and provides potentially useful extra info
> > > >
> > > > As mentioned before, there is already a concept of pressure in the multi-touch
> > > > protocol, generally used as a proxy for contact area. We would add another field
> > > > to represent force. However, the pressure field is defined by the protocol as
> > > > actual pressure, and I feel this would only add more confusion. The touch_major
> > > > and touch_minor fields can be used to report contact area explicitly, so we're
> > > > not losing that capability.
> > >
> > > Nope, I am not buying this idea. As mentioned above, the MT_PRESSURE
> > > was always intended to report the pressure of the contact. It is an
> > > approximation in the capacitive sensor case, but there is no point in
> > > adding one new event. Also, if we set the INPUT_PROP_FORCEPAD, it is
> > > now clear that the unit and thus the resolution is reliable.
> > >
> > > >
> > > > Report overall force, but not per-contact force
> > > > -----------------------------------------------
> > > >
> > > > Instead of reporting the “traditional pressure,” send “true force” values in the
> > > > ABS_PRESSURE field.The ABS_MT_PRESSURE field would still be used to send
> > > > “traditional pressure” for each contact.
> > > >
> > > > I'm not convinced this is necessary, or the best idea. It makes backward
> > > > compatibility easy, but other input libraries could detect forcepads by the
> > > > resolution associated with the ABS_MT_PRESSURE field, and ignore that field,
> > > > using touch_major and touch_minor instead.
> > > >
> > > > In addition, it adds even more confusion than the above option, so I think I'd
> > > > prefer a clean break.
> > >
> > > I think I like having the ABS_PRESSURE as the total force applied. But
> > > we need per-contact force if this is available.
> > > And again, I don't think we should mention the "traditional pressure"
> > > as this is just a quirk from the capacitive sensors, and the actual
> > > pressure was reported before those sensors came mainstream (think of
> > > resistive ones).
> > >
> > > >
> > > > Use driver-wide gain for force feedback
> > > > ---------------------------------------
> > > >
> > > > The force feedback protocol also has a mechanism to set driver-wide gain, which
> > > > could be used to set global effect strength level. However, allowing different
> > > > strength levels for each predefined effect would allow more flexibility e.g.: if
> > > > the user wants to have low strength for UI feedback effects and high strength
> > > > for button click effects.
> > >
> > > I also think the best would be to have per effect intensity.
> > >
> > > Anyway, thanks a lot for putting the effort in this.
> > >
> > > The last bit I wanted to add is that we should define properly the
> > > haptic and touch protocol in a way that we can support non simple
> > > haptic HID controllers. For example, I doubt the Apple forcepad
> > > follows the HID spec, but if the driver can provide the same level of
> > > quality we require to mark a device as INPUT_PROP_FORCEPAD, we don't
> > > really care if the haptic interface is HID or not.
> > >
> > > Cheers,
> > > Benjamin
> > >
> > > >
> > > > [0]: https://www.kernel.org/doc/Documentation/input/multi-touch-protocol.txt
> > > > [1]: https://www.kernel.org/doc/Documentation/input/ff.txt
> > > > [2]: https://www.usb.org/sites/default/files/hutrr63b_-_haptics_page_redline_0.pdf
> > > > [3]: Usage ID 0x30 of HID usage table 0x0D. See chapter 16:
> > > > https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf
> > > > [4]: See section 6.2.2.7 of the HID specification:
> > > > https://www.usb.org/sites/default/files/documents/hid1_11.pdf
