libinput pressure detection: clarification for drivers

Peter Hutterer peter.hutterer at
Tue Mar 7 00:16:09 UTC 2017

On Mon, Mar 06, 2017 at 12:40:52AM -0800, Life is hard, and then you die wrote:
> On Mon, Mar 06, 2017 at 01:08:48PM +1000, Peter Hutterer wrote:
> > On Fri, Mar 03, 2017 at 06:41:31PM -0800, Life is hard, and then you die wrote:
> > > 
> > > I was testing out the new pressure-based touch detection in libinput
> > > (on a new MBP where the sensitivy is such that it's been possible to
> > > move the mouse without actually touching the touchpad, so this new
> > > feature is very welcome) and realized that it appears the drivers must
> > > send actual ABS_MT_PRESSURE or ABS_PRESSURE events. 
> > 
> > fwiw, "must" is a bit strongly worded here. Yes, libinput currently only
> > looks at either of those two but there's no reason we can't look at anything
> > else. Main problem is that of time and device availability, almost all
> > touchpad devices I see have pressure, few have touch major/minor.
> > 
> > And the ones that do send relatively random values for those, despite them
> > being supposedly well-defined. That's at least true for the touchscreens
> > I've seen, not sure on touchpads.
> I see. Presumably you need to scale the touch major/minor values to
> physical dimensions, but even then they aren't reliable?

iirc, the touchscreen I have here claims that the touch ellipsis is 0.4 mm
which even with optimistic rounding it is a bit small :)
but if you get yours to report precise-enough data, we can use it.

> > > From reading the
> > > kernel documentation at
> > >
> > > I was under the impression that these events were only needed for
> > > devices that didn't provide ABS_MT_TOUCH_MAJOR/ABS_MT_WIDTH_MAJOR .
> > > 
> > > So my question is basically: am I misreading the above doc, and should
> > > drivers then always report pressure events even if they already report
> > > touch and width events?
> > 
> > Do what the kernel doc says and let's add major/minor to libinput, that's
> > the long-term plan forward.
> Ok. But near term I guess I should go ahead with reporting
> ABS_MT_PRESSURE in the driver (Btw., I'm talking about the bcm5974
> clone for SPI keyboards+touchpads at

yes, if you report pressure you have the advantage of things working right
now, at least until we start using the major/minor axes.

> > > Btw., I noticed that the bcm5974 driver only sends only ABS_PRESSURE
> > > (not ABS_MT_PRESSURE) even though it has the ABS_MT_SLOT capability
> > > set, so AFAICT the pressure-detection won't work for that device (and
> > > the emulation in test/litest-device-bcm5974.c seems misleading since
> > > that is sending ABS_MT_PRESSURE events).
> > 
> > oh, oops. Can you file a bug for that please so I can get that fixed?
> > thanks.
> Sorry, a bug where? With the bcm5974 driver? It seems to generate
> ABS_WIDTH and ABS_PRESSURE for backwards compatibility reasons with
> Xorg synaptics drivers, so it's not clear if not generating
> ABS_MT_PRESSURE would be considered a bug.

the test devices are supposed to be exact copies of the real devices to make
sure we don't break any real devices when we change anything, so if the real
bcm5974 sends different events to our test device, we need to fix the test
device - tldr: bug in libinput please, thanks :)


More information about the wayland-devel mailing list