Re: [PATCH libinput 6/8] tablet: support tool-specific pressure offsets
On Sunday, December 13, 2015, Peter Hutterer
wrote:
> If a tool wears out, it may have a pre-loaded pressure offset. In that
> case,
> even when the tool is not physically in contact with the tablet surface it
> will send pressure events.
>
> Use automatic pressure offset detection, similar to what the X.Org wacom
> driver does. On proximity-in, check the pressure and if the distance is
> above
> 50% of the range and the pressure is nonzero but below 20% of the range,
> use
> that value as pressure offset.
>
> Signed-off-by: Peter Hutterer >
There is no logical change in this version. So, it is still
Reviewed-by: Ping Cheng
Ping
---
> Changes to v2:
> - rather than using offset != INT_MIN everywhere, add a has_pressure_offset
> boolean and check that. Makes the code much nicer
>
> doc/tablet-support.dox | 29 +++
> src/evdev-tablet.c | 86 -
> src/evdev-tablet.h | 21 +++
> src/libinput-private.h | 3 +
> test/litest-device-wacom-intuos-tablet.c | 1 +
> test/tablet.c| 313
> ++-
> 6 files changed, 449 insertions(+), 4 deletions(-)
>
> diff --git a/doc/tablet-support.dox b/doc/tablet-support.dox
> index 24d08d2..5468c6f 100644
> --- a/doc/tablet-support.dox
> +++ b/doc/tablet-support.dox
> @@ -92,4 +92,33 @@ if (value < min) {
> }
> @endcode
>
> +@section tablet-pressure-offset Pressure offset on worn-out tools
> +
> +When a tool is used for an extended period it can wear down physically. A
> +worn-down tool may never return a zero pressure value. Even when hovering
> +above the surface, the pressure value returned by the tool is nonzero,
> +creating a fake surface touch and making interaction with the tablet less
> +predictable.
> +
> +libinput automatically detects pressure offsets and rescales the remaining
> +pressure range into the available range, making pressure-offsets
> transparent
> +to the caller. A tool with a pressure offset will thus send a 0 pressure
> +value for the detected offset and nonzero pressure values for values
> higher
> +than that offset.
> +
> +Some limitations apply to avoid misdetection of pressure offsets,
> +specifically:
> +- pressure offset is only detected on proximity in, and if a device is
> + capable of detection distances,
> +- pressure offset is only detected if the distance between the tool and
> the
> + tablet is high enough,
> +- pressure offset is only used if it is 20% or less of the pressure range
> + available to the tool. A pressure offset higher than 20% indicates
> either
> + a misdetection or a tool that should be replaced, and
> +- if a pressure value less than the current pressure offset is seen, the
> + offset resets to that value.
> +
> +Pressure offsets are not detected on @ref LIBINPUT_TABLET_TOOL_TYPE_MOUSE
> +and @ref LIBINPUT_TABLET_TOOL_TYPE_LENS tools.
> +
> */
> diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
> index cd208a8..2a45575 100644
> --- a/src/evdev-tablet.c
> +++ b/src/evdev-tablet.c
> @@ -21,9 +21,11 @@
> * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> */
> #include "config.h"
> +#include "libinput-version.h"
> #include "evdev-tablet.h"
>
> #include
> +#include
> #include
> #include
>
> @@ -202,7 +204,7 @@ tablet_update_tool(struct tablet_dispatch *tablet,
> }
>
> static inline double
> -normalize_pressure_dist_slider(const struct input_absinfo *absinfo)
> +normalize_dist_slider(const struct input_absinfo *absinfo)
> {
> double range = absinfo->maximum - absinfo->minimum;
> double value = (absinfo->value - absinfo->minimum) / range;
> @@ -211,6 +213,18 @@ normalize_pressure_dist_slider(const struct
> input_absinfo *absinfo)
> }
>
> static inline double
> +normalize_pressure(const struct input_absinfo *absinfo,
> + struct libinput_tablet_tool *tool)
> +{
> + double range = absinfo->maximum - absinfo->minimum;
> + int offset = tool->has_pressure_offset ?
> + tool->pressure_offset : 0;
> + double value = (absinfo->value - offset - absinfo->minimum) /
> range;
> +
> + return value;
> +}
> +
> +static inline double
> normalize_tilt(const struct input_absinfo *absinfo)
> {
> double range = absinfo->maximum - absinfo->minimum;
> @@ -405,10 +419,12 @@ tablet_check_notify_axes(struct tablet_dispatch
> *tablet,
> else
> tablet->axes[a] = absinfo->value;
> break;
> - case LIBINPUT_TABLET_TOOL_AXIS_DISTANCE:
> case LIBINPUT_TABLET_TOOL_AXIS_PRESSURE:
> + tablet->axes[a] = normalize_pressure(absinfo,
> tool);
> + break;
> + case LIBINPUT_TABLET_TOOL_AXIS_DISTANCE:
> case LIBINPUT_TABLET_TOOL_AXIS_SLIDER:
> - tablet->axes[a] =
> normalize_pressure_dist_sl
Re: [PATCH libinput 6/8] tablet: support tool-specific pressure offsets
On Tue, Dec 08, 2015 at 05:37:52PM -0800, Jason Gerecke wrote: > On Sun, Dec 6, 2015 at 8:22 PM, Peter Hutterer > wrote: > > On Thu, Dec 03, 2015 at 07:57:30PM -0800, Jason Gerecke wrote: > >> On Wed, Dec 2, 2015 at 5:03 PM, Peter Hutterer > >> wrote: > >> > On Wed, Dec 02, 2015 at 04:21:56PM -0800, Jason Gerecke wrote: > >> >> On Tue, Dec 1, 2015 at 5:46 PM, Peter Hutterer > >> >> wrote: > >> >> > If a tool wears out, it may have a pre-loaded pressure offset. In > >> >> > that case, > >> >> > even when the tool is not physically in contact with the tablet > >> >> > surface it > >> >> > will send pressure events. > >> >> > > >> >> > The X.Org wacom driver has automatic pressure preload detection, but > >> >> > it is > >> >> > unreliable. A quick tap can trigger the detection, making the pen > >> >> > unusable > >> >> > (see xf86-input-wacom-0.23.0-43-g10cc765). > >> >> > > >> >> > Since this is a hardware-specific property, add a new udev property > >> >> > with the > >> >> > prefix TABLET_TOOL_PRESSURE_OFFSET_ and let it be set system-wide > >> >> > through the > >> >> > hwdb or some other process. Use the value of this property to offset > >> >> > any > >> >> > incoming pressure values and scale into the original normalized axis > >> >> > range. > >> >> > > >> >> > Signed-off-by: Peter Hutterer > >> >> > >> >> I've been asked by Ping (who is going to be OOO for the next few days) > >> >> to try and express some of her concerns about how libinput will handle > >> >> pen pressure. The two of us have had some lengthy discussions, and > >> >> though I'm not sure I agree on all points, I'll try to argue them as > >> >> best I can. > >> >> > >> >> The idea behind the X driver's automatic preload detection was to > >> >> provide a way to handle the pen-specific pressure offsets without > >> >> requiring the user to configure or calibrate anything. The minimum > >> >> pressure seen from a pen is a fairly reliable measure of the offset, > >> >> and the X driver attempts to measure this as the pen hovers in > >> >> proximity. This works well in most circumstances, but obviously fails > >> >> if the pen is "stabbed" at the tablet so quickly that it comes into > >> >> contact before it can report an unloaded pressure value. This kind of > >> >> wanton hardware abuse isn't something we encourage ;) > >> >> > >> >> Making the pressure offset a configuration option like you propose > >> >> here doesn't suffer from mis-detection, but does require the user to > >> >> periodically run a tool to update the UDEV HWDB. Updates to the DB > >> >> won't take immediate effect[1], won't propagate across systems[2], and > >> >> are incapable of distinguishing between tools without a serial number. > >> > > >> > a couple of questions here: > >> > * how common is this pressure preload? > >> > * does it affect all pens or only specific pens? > >> > * is there a maximum observed threshold for this pen preload? > >> > > >> > The last one is specifically: is there a point where we can throw up our > >> > hands and tell the user to just buy a new pen rather than needing > >> > automatic > >> > detection *and* the udev property for anything that exceeds that > >> > threshold? > >> > > >> > >> Pens which are fresh from the factory or only lightly used (e.g., all > >> the pens in my office...) should have a preload of zero. As time goes > >> on and the pen's pressure transducer starts to wear out (especially if > >> the pen is "abused") the preload will increase. Unfortunately, I don't > >> have any data on how quickly preload accumulates or what ranges of > >> values might be expected in the wild. The X driver logs a warning when > >> the preload exceeds 20% of maximum pressure, but the origin of that > >> particular number is unknown. > > > > that number was simply made up, based on the assumption that if you're > > losing 1/5 of your pressure range (and thus granularity) then it's probably > > time to get a new tool. it's a relatively recent commit, so maybe this is > > more common than expected. > > > >> >> One change that could be made to the automatic method that would make > >> >> it a bit more reliable would be to define a maximum pressure that it > >> >> would consider to be a sane preload. A 'stabbed' pen would almost > >> >> certainly overshoot the ceiling and we could simply assume an > >> >> arbitrary preload of our choosing (zero? the ceiling?). A very light > >> >> 'stab' could still cause issues, but its quite difficult to both move > >> >> the pen quickly enough to enter and exit prox at a high enough speed > >> >> to not get an unloaded pressure reading *and* only lightly come into > >> >> contact with the surface. > >> > > >> > at least on the tablets that do distance we can combine the maximum > >> > pressure > >> > threshold with the distance measurement. It's harder to do that on > >> > tablets > >> > without distance though. > >> > > >> > >> The distance data is pretty rough and I believe varies bas
Re: [PATCH libinput 6/8] tablet: support tool-specific pressure offsets
On Sun, Dec 6, 2015 at 8:22 PM, Peter Hutterer wrote: > On Thu, Dec 03, 2015 at 07:57:30PM -0800, Jason Gerecke wrote: >> On Wed, Dec 2, 2015 at 5:03 PM, Peter Hutterer >> wrote: >> > On Wed, Dec 02, 2015 at 04:21:56PM -0800, Jason Gerecke wrote: >> >> On Tue, Dec 1, 2015 at 5:46 PM, Peter Hutterer >> >> wrote: >> >> > If a tool wears out, it may have a pre-loaded pressure offset. In that >> >> > case, >> >> > even when the tool is not physically in contact with the tablet surface >> >> > it >> >> > will send pressure events. >> >> > >> >> > The X.Org wacom driver has automatic pressure preload detection, but it >> >> > is >> >> > unreliable. A quick tap can trigger the detection, making the pen >> >> > unusable >> >> > (see xf86-input-wacom-0.23.0-43-g10cc765). >> >> > >> >> > Since this is a hardware-specific property, add a new udev property >> >> > with the >> >> > prefix TABLET_TOOL_PRESSURE_OFFSET_ and let it be set system-wide >> >> > through the >> >> > hwdb or some other process. Use the value of this property to offset any >> >> > incoming pressure values and scale into the original normalized axis >> >> > range. >> >> > >> >> > Signed-off-by: Peter Hutterer >> >> >> >> I've been asked by Ping (who is going to be OOO for the next few days) >> >> to try and express some of her concerns about how libinput will handle >> >> pen pressure. The two of us have had some lengthy discussions, and >> >> though I'm not sure I agree on all points, I'll try to argue them as >> >> best I can. >> >> >> >> The idea behind the X driver's automatic preload detection was to >> >> provide a way to handle the pen-specific pressure offsets without >> >> requiring the user to configure or calibrate anything. The minimum >> >> pressure seen from a pen is a fairly reliable measure of the offset, >> >> and the X driver attempts to measure this as the pen hovers in >> >> proximity. This works well in most circumstances, but obviously fails >> >> if the pen is "stabbed" at the tablet so quickly that it comes into >> >> contact before it can report an unloaded pressure value. This kind of >> >> wanton hardware abuse isn't something we encourage ;) >> >> >> >> Making the pressure offset a configuration option like you propose >> >> here doesn't suffer from mis-detection, but does require the user to >> >> periodically run a tool to update the UDEV HWDB. Updates to the DB >> >> won't take immediate effect[1], won't propagate across systems[2], and >> >> are incapable of distinguishing between tools without a serial number. >> > >> > a couple of questions here: >> > * how common is this pressure preload? >> > * does it affect all pens or only specific pens? >> > * is there a maximum observed threshold for this pen preload? >> > >> > The last one is specifically: is there a point where we can throw up our >> > hands and tell the user to just buy a new pen rather than needing automatic >> > detection *and* the udev property for anything that exceeds that threshold? >> > >> >> Pens which are fresh from the factory or only lightly used (e.g., all >> the pens in my office...) should have a preload of zero. As time goes >> on and the pen's pressure transducer starts to wear out (especially if >> the pen is "abused") the preload will increase. Unfortunately, I don't >> have any data on how quickly preload accumulates or what ranges of >> values might be expected in the wild. The X driver logs a warning when >> the preload exceeds 20% of maximum pressure, but the origin of that >> particular number is unknown. > > that number was simply made up, based on the assumption that if you're > losing 1/5 of your pressure range (and thus granularity) then it's probably > time to get a new tool. it's a relatively recent commit, so maybe this is > more common than expected. > >> >> One change that could be made to the automatic method that would make >> >> it a bit more reliable would be to define a maximum pressure that it >> >> would consider to be a sane preload. A 'stabbed' pen would almost >> >> certainly overshoot the ceiling and we could simply assume an >> >> arbitrary preload of our choosing (zero? the ceiling?). A very light >> >> 'stab' could still cause issues, but its quite difficult to both move >> >> the pen quickly enough to enter and exit prox at a high enough speed >> >> to not get an unloaded pressure reading *and* only lightly come into >> >> contact with the surface. >> > >> > at least on the tablets that do distance we can combine the maximum >> > pressure >> > threshold with the distance measurement. It's harder to do that on tablets >> > without distance though. >> > >> >> The distance data is pretty rough and I believe varies based on the >> environment (since its similar to [but I don't think /quite/ the same >> as] SNR) but that still might be an interesting idea. If the driver >> has a reasonable idea of a minimum "safe" distance where the pen is >> almost certainly not in contact, then it can figure out i
Re: [PATCH libinput 6/8] tablet: support tool-specific pressure offsets
On Sun, Dec 6, 2015 at 8:22 PM, Peter Hutterer wrote: > > if you touch the surface so light that it flickers between 0 and nonzero > pressure, then the up/down storm is representative of the user's action. > That is not the case when you have a magic threshold, because you can > trigger the up/down storm even while holding the stylus down on the tablet. > > I think he means there to be a different (higher) threshold for down than up. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 6/8] tablet: support tool-specific pressure offsets
On Thu, Dec 03, 2015 at 07:57:30PM -0800, Jason Gerecke wrote: > On Wed, Dec 2, 2015 at 5:03 PM, Peter Hutterer > wrote: > > On Wed, Dec 02, 2015 at 04:21:56PM -0800, Jason Gerecke wrote: > >> On Tue, Dec 1, 2015 at 5:46 PM, Peter Hutterer > >> wrote: > >> > If a tool wears out, it may have a pre-loaded pressure offset. In that > >> > case, > >> > even when the tool is not physically in contact with the tablet surface > >> > it > >> > will send pressure events. > >> > > >> > The X.Org wacom driver has automatic pressure preload detection, but it > >> > is > >> > unreliable. A quick tap can trigger the detection, making the pen > >> > unusable > >> > (see xf86-input-wacom-0.23.0-43-g10cc765). > >> > > >> > Since this is a hardware-specific property, add a new udev property with > >> > the > >> > prefix TABLET_TOOL_PRESSURE_OFFSET_ and let it be set system-wide > >> > through the > >> > hwdb or some other process. Use the value of this property to offset any > >> > incoming pressure values and scale into the original normalized axis > >> > range. > >> > > >> > Signed-off-by: Peter Hutterer > >> > >> I've been asked by Ping (who is going to be OOO for the next few days) > >> to try and express some of her concerns about how libinput will handle > >> pen pressure. The two of us have had some lengthy discussions, and > >> though I'm not sure I agree on all points, I'll try to argue them as > >> best I can. > >> > >> The idea behind the X driver's automatic preload detection was to > >> provide a way to handle the pen-specific pressure offsets without > >> requiring the user to configure or calibrate anything. The minimum > >> pressure seen from a pen is a fairly reliable measure of the offset, > >> and the X driver attempts to measure this as the pen hovers in > >> proximity. This works well in most circumstances, but obviously fails > >> if the pen is "stabbed" at the tablet so quickly that it comes into > >> contact before it can report an unloaded pressure value. This kind of > >> wanton hardware abuse isn't something we encourage ;) > >> > >> Making the pressure offset a configuration option like you propose > >> here doesn't suffer from mis-detection, but does require the user to > >> periodically run a tool to update the UDEV HWDB. Updates to the DB > >> won't take immediate effect[1], won't propagate across systems[2], and > >> are incapable of distinguishing between tools without a serial number. > > > > a couple of questions here: > > * how common is this pressure preload? > > * does it affect all pens or only specific pens? > > * is there a maximum observed threshold for this pen preload? > > > > The last one is specifically: is there a point where we can throw up our > > hands and tell the user to just buy a new pen rather than needing automatic > > detection *and* the udev property for anything that exceeds that threshold? > > > > Pens which are fresh from the factory or only lightly used (e.g., all > the pens in my office...) should have a preload of zero. As time goes > on and the pen's pressure transducer starts to wear out (especially if > the pen is "abused") the preload will increase. Unfortunately, I don't > have any data on how quickly preload accumulates or what ranges of > values might be expected in the wild. The X driver logs a warning when > the preload exceeds 20% of maximum pressure, but the origin of that > particular number is unknown. that number was simply made up, based on the assumption that if you're losing 1/5 of your pressure range (and thus granularity) then it's probably time to get a new tool. it's a relatively recent commit, so maybe this is more common than expected. > >> One change that could be made to the automatic method that would make > >> it a bit more reliable would be to define a maximum pressure that it > >> would consider to be a sane preload. A 'stabbed' pen would almost > >> certainly overshoot the ceiling and we could simply assume an > >> arbitrary preload of our choosing (zero? the ceiling?). A very light > >> 'stab' could still cause issues, but its quite difficult to both move > >> the pen quickly enough to enter and exit prox at a high enough speed > >> to not get an unloaded pressure reading *and* only lightly come into > >> contact with the surface. > > > > at least on the tablets that do distance we can combine the maximum pressure > > threshold with the distance measurement. It's harder to do that on tablets > > without distance though. > > > > The distance data is pretty rough and I believe varies based on the > environment (since its similar to [but I don't think /quite/ the same > as] SNR) but that still might be an interesting idea. If the driver > has a reasonable idea of a minimum "safe" distance where the pen is > almost certainly not in contact, then it can figure out if the > pressure can be interpreted as preload or not. it'd be great if you can talk to your hw engineers or other driver teams to figure out whether we can
Re: [PATCH libinput 6/8] tablet: support tool-specific pressure offsets
On Wed, Dec 2, 2015 at 5:03 PM, Peter Hutterer wrote: > On Wed, Dec 02, 2015 at 04:21:56PM -0800, Jason Gerecke wrote: >> On Tue, Dec 1, 2015 at 5:46 PM, Peter Hutterer >> wrote: >> > If a tool wears out, it may have a pre-loaded pressure offset. In that >> > case, >> > even when the tool is not physically in contact with the tablet surface it >> > will send pressure events. >> > >> > The X.Org wacom driver has automatic pressure preload detection, but it is >> > unreliable. A quick tap can trigger the detection, making the pen unusable >> > (see xf86-input-wacom-0.23.0-43-g10cc765). >> > >> > Since this is a hardware-specific property, add a new udev property with >> > the >> > prefix TABLET_TOOL_PRESSURE_OFFSET_ and let it be set system-wide through >> > the >> > hwdb or some other process. Use the value of this property to offset any >> > incoming pressure values and scale into the original normalized axis range. >> > >> > Signed-off-by: Peter Hutterer >> >> I've been asked by Ping (who is going to be OOO for the next few days) >> to try and express some of her concerns about how libinput will handle >> pen pressure. The two of us have had some lengthy discussions, and >> though I'm not sure I agree on all points, I'll try to argue them as >> best I can. >> >> The idea behind the X driver's automatic preload detection was to >> provide a way to handle the pen-specific pressure offsets without >> requiring the user to configure or calibrate anything. The minimum >> pressure seen from a pen is a fairly reliable measure of the offset, >> and the X driver attempts to measure this as the pen hovers in >> proximity. This works well in most circumstances, but obviously fails >> if the pen is "stabbed" at the tablet so quickly that it comes into >> contact before it can report an unloaded pressure value. This kind of >> wanton hardware abuse isn't something we encourage ;) >> >> Making the pressure offset a configuration option like you propose >> here doesn't suffer from mis-detection, but does require the user to >> periodically run a tool to update the UDEV HWDB. Updates to the DB >> won't take immediate effect[1], won't propagate across systems[2], and >> are incapable of distinguishing between tools without a serial number. > > a couple of questions here: > * how common is this pressure preload? > * does it affect all pens or only specific pens? > * is there a maximum observed threshold for this pen preload? > > The last one is specifically: is there a point where we can throw up our > hands and tell the user to just buy a new pen rather than needing automatic > detection *and* the udev property for anything that exceeds that threshold? > Pens which are fresh from the factory or only lightly used (e.g., all the pens in my office...) should have a preload of zero. As time goes on and the pen's pressure transducer starts to wear out (especially if the pen is "abused") the preload will increase. Unfortunately, I don't have any data on how quickly preload accumulates or what ranges of values might be expected in the wild. The X driver logs a warning when the preload exceeds 20% of maximum pressure, but the origin of that particular number is unknown. >> One change that could be made to the automatic method that would make >> it a bit more reliable would be to define a maximum pressure that it >> would consider to be a sane preload. A 'stabbed' pen would almost >> certainly overshoot the ceiling and we could simply assume an >> arbitrary preload of our choosing (zero? the ceiling?). A very light >> 'stab' could still cause issues, but its quite difficult to both move >> the pen quickly enough to enter and exit prox at a high enough speed >> to not get an unloaded pressure reading *and* only lightly come into >> contact with the surface. > > at least on the tablets that do distance we can combine the maximum pressure > threshold with the distance measurement. It's harder to do that on tablets > without distance though. > The distance data is pretty rough and I believe varies based on the environment (since its similar to [but I don't think /quite/ the same as] SNR) but that still might be an interesting idea. If the driver has a reasonable idea of a minimum "safe" distance where the pen is almost certainly not in contact, then it can figure out if the pressure can be interpreted as preload or not. >> A second issue that Ping brought up is the tying of pressure >> information to the "down" state (patch 4). Its possible that a user >> would want to have the maximum possible dynamic range for pressure >> (after accounting for the preload) in a drawing app so that the >> lightest strokes were useful, while simultaneously wanting UI elements >> like buttons and menus to only respond to more deliberate (and >> high-pressure) pen events. In terms of protocol and library, this >> would mean allowing applications to see non-zero pressure values even >> before the pen is "down". If we want to do this, we would
Re: [PATCH libinput 6/8] tablet: support tool-specific pressure offsets
On Wed, Dec 02, 2015 at 04:21:56PM -0800, Jason Gerecke wrote: > On Tue, Dec 1, 2015 at 5:46 PM, Peter Hutterer > wrote: > > If a tool wears out, it may have a pre-loaded pressure offset. In that case, > > even when the tool is not physically in contact with the tablet surface it > > will send pressure events. > > > > The X.Org wacom driver has automatic pressure preload detection, but it is > > unreliable. A quick tap can trigger the detection, making the pen unusable > > (see xf86-input-wacom-0.23.0-43-g10cc765). > > > > Since this is a hardware-specific property, add a new udev property with the > > prefix TABLET_TOOL_PRESSURE_OFFSET_ and let it be set system-wide through > > the > > hwdb or some other process. Use the value of this property to offset any > > incoming pressure values and scale into the original normalized axis range. > > > > Signed-off-by: Peter Hutterer > > I've been asked by Ping (who is going to be OOO for the next few days) > to try and express some of her concerns about how libinput will handle > pen pressure. The two of us have had some lengthy discussions, and > though I'm not sure I agree on all points, I'll try to argue them as > best I can. > > The idea behind the X driver's automatic preload detection was to > provide a way to handle the pen-specific pressure offsets without > requiring the user to configure or calibrate anything. The minimum > pressure seen from a pen is a fairly reliable measure of the offset, > and the X driver attempts to measure this as the pen hovers in > proximity. This works well in most circumstances, but obviously fails > if the pen is "stabbed" at the tablet so quickly that it comes into > contact before it can report an unloaded pressure value. This kind of > wanton hardware abuse isn't something we encourage ;) > > Making the pressure offset a configuration option like you propose > here doesn't suffer from mis-detection, but does require the user to > periodically run a tool to update the UDEV HWDB. Updates to the DB > won't take immediate effect[1], won't propagate across systems[2], and > are incapable of distinguishing between tools without a serial number. a couple of questions here: * how common is this pressure preload? * does it affect all pens or only specific pens? * is there a maximum observed threshold for this pen preload? The last one is specifically: is there a point where we can throw up our hands and tell the user to just buy a new pen rather than needing automatic detection *and* the udev property for anything that exceeds that threshold? > One change that could be made to the automatic method that would make > it a bit more reliable would be to define a maximum pressure that it > would consider to be a sane preload. A 'stabbed' pen would almost > certainly overshoot the ceiling and we could simply assume an > arbitrary preload of our choosing (zero? the ceiling?). A very light > 'stab' could still cause issues, but its quite difficult to both move > the pen quickly enough to enter and exit prox at a high enough speed > to not get an unloaded pressure reading *and* only lightly come into > contact with the surface. at least on the tablets that do distance we can combine the maximum pressure threshold with the distance measurement. It's harder to do that on tablets without distance though. > A second issue that Ping brought up is the tying of pressure > information to the "down" state (patch 4). Its possible that a user > would want to have the maximum possible dynamic range for pressure > (after accounting for the preload) in a drawing app so that the > lightest strokes were useful, while simultaneously wanting UI elements > like buttons and menus to only respond to more deliberate (and > high-pressure) pen events. In terms of protocol and library, this > would mean allowing applications to see non-zero pressure values even > before the pen is "down". If we want to do this, we would have to be > very deliberate in documenting that the behavior so that programmers > understand the pressure data is useful and should not be discarded (or > if absolutely necessary, rescaled so that the click threshold is > reported as 0 pressure). Right now I don't think any toolkits or > applications make use of pressure prior to click, though TBH I haven't > actually checked... long-term I want the tip down/up to match a distance 0 and have anything with distance not send any pressure. The current BTN_TOUCH handling isn't ideal because it discards lower pressure values, I think we should use a libinput-internal pressure threshold here and fake the BTN_TOUCH based on that. And the range between max(threshold, preload)-axis_max will then be mapped into the normalised range. So the logic will likely be tilted towards the pressure, with finer-grained distance measuring: * if the distance > threshold and pressure != 0 -> pressure preload * if the distance < other threshold and pressure > preload -> distance 0 this makes BTN_TOUCH relati
Re: [PATCH libinput 6/8] tablet: support tool-specific pressure offsets
On Tue, Dec 1, 2015 at 5:46 PM, Peter Hutterer wrote: > If a tool wears out, it may have a pre-loaded pressure offset. In that case, > even when the tool is not physically in contact with the tablet surface it > will send pressure events. > > The X.Org wacom driver has automatic pressure preload detection, but it is > unreliable. A quick tap can trigger the detection, making the pen unusable > (see xf86-input-wacom-0.23.0-43-g10cc765). > > Since this is a hardware-specific property, add a new udev property with the > prefix TABLET_TOOL_PRESSURE_OFFSET_ and let it be set system-wide through the > hwdb or some other process. Use the value of this property to offset any > incoming pressure values and scale into the original normalized axis range. > > Signed-off-by: Peter Hutterer I've been asked by Ping (who is going to be OOO for the next few days) to try and express some of her concerns about how libinput will handle pen pressure. The two of us have had some lengthy discussions, and though I'm not sure I agree on all points, I'll try to argue them as best I can. The idea behind the X driver's automatic preload detection was to provide a way to handle the pen-specific pressure offsets without requiring the user to configure or calibrate anything. The minimum pressure seen from a pen is a fairly reliable measure of the offset, and the X driver attempts to measure this as the pen hovers in proximity. This works well in most circumstances, but obviously fails if the pen is "stabbed" at the tablet so quickly that it comes into contact before it can report an unloaded pressure value. This kind of wanton hardware abuse isn't something we encourage ;) Making the pressure offset a configuration option like you propose here doesn't suffer from mis-detection, but does require the user to periodically run a tool to update the UDEV HWDB. Updates to the DB won't take immediate effect[1], won't propagate across systems[2], and are incapable of distinguishing between tools without a serial number. One change that could be made to the automatic method that would make it a bit more reliable would be to define a maximum pressure that it would consider to be a sane preload. A 'stabbed' pen would almost certainly overshoot the ceiling and we could simply assume an arbitrary preload of our choosing (zero? the ceiling?). A very light 'stab' could still cause issues, but its quite difficult to both move the pen quickly enough to enter and exit prox at a high enough speed to not get an unloaded pressure reading *and* only lightly come into contact with the surface. A second issue that Ping brought up is the tying of pressure information to the "down" state (patch 4). Its possible that a user would want to have the maximum possible dynamic range for pressure (after accounting for the preload) in a drawing app so that the lightest strokes were useful, while simultaneously wanting UI elements like buttons and menus to only respond to more deliberate (and high-pressure) pen events. In terms of protocol and library, this would mean allowing applications to see non-zero pressure values even before the pen is "down". If we want to do this, we would have to be very deliberate in documenting that the behavior so that programmers understand the pressure data is useful and should not be discarded (or if absolutely necessary, rescaled so that the click threshold is reported as 0 pressure). Right now I don't think any toolkits or applications make use of pressure prior to click, though TBH I haven't actually checked... [1]: I know you can use `udevadm --reload`, but that doesn't affect already-connected devices [2]: The automatic detection doesn't require re-calibrating a pen on every system its used on Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three,/ So you look at the sixty-fours > --- > doc/device-configuration-via-udev.dox| 4 + > doc/tablet-support.dox | 30 ++ > src/evdev-tablet.c | 71 +- > src/libinput-private.h | 2 + > test/litest-device-wacom-intuos-tablet.c | 12 +++ > test/tablet.c| 155 > ++- > 6 files changed, 270 insertions(+), 4 deletions(-) > > diff --git a/doc/device-configuration-via-udev.dox > b/doc/device-configuration-via-udev.dox > index f615cc1..ba44e58 100644 > --- a/doc/device-configuration-via-udev.dox > +++ b/doc/device-configuration-via-udev.dox > @@ -63,6 +63,10 @@ libinput_pointer_get_axis_source() for details. > POINTINGSTICK_CONST_ACCEL > A constant (linear) acceleration factor to apply to pointingstick deltas > to normalize them. > +TABLET_TOOL_PRESSURE_OFFSET_* > +Specifies the pressure offset in device coordinates for the tool whose > +name is given as part of the property name. See @ref tablet-pressure-offset > +for deta
Re: [PATCH libinput 6/8] tablet: support tool-specific pressure offsets
On Tue, Dec 1, 2015 at 5:46 PM, Peter Hutterer
wrote:
>
> + switch (tool->type) {
> + case LIBINPUT_TABLET_TOOL_TYPE_PEN:
> + strtype = "PEN";
> + break;
> + case LIBINPUT_TABLET_TOOL_TYPE_BRUSH:
> + strtype = "BRUSH";
> + break;
> + case LIBINPUT_TABLET_TOOL_TYPE_AIRBRUSH:
> + strtype = "AIRBRUSH";
> + break;
> + case LIBINPUT_TABLET_TOOL_TYPE_PENCIL:
> + strtype = "PENCIL";
> + break;
> + case LIBINPUT_TABLET_TOOL_TYPE_ERASER:
> + strtype = "RUBBER";
> + break;
>
> Is there a good reason for this inconsistency in the strings? Ie why isn't
the last strtype "ERASER".
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 6/8] tablet: support tool-specific pressure offsets
On Tue, Dec 01, 2015 at 06:48:41PM -0800, Bill Spitzak wrote:
> On Tue, Dec 1, 2015 at 5:46 PM, Peter Hutterer
> wrote:
>
> >
> > + switch (tool->type) {
> > + case LIBINPUT_TABLET_TOOL_TYPE_PEN:
> > + strtype = "PEN";
> > + break;
> > + case LIBINPUT_TABLET_TOOL_TYPE_BRUSH:
> > + strtype = "BRUSH";
> > + break;
> > + case LIBINPUT_TABLET_TOOL_TYPE_AIRBRUSH:
> > + strtype = "AIRBRUSH";
> > + break;
> > + case LIBINPUT_TABLET_TOOL_TYPE_PENCIL:
> > + strtype = "PENCIL";
> > + break;
> > + case LIBINPUT_TABLET_TOOL_TYPE_ERASER:
> > + strtype = "RUBBER";
> > + break;
> >
> > Is there a good reason for this inconsistency in the strings? Ie why isn't
> the last strtype "ERASER".
I suspect whoever submitted the linux/input.h patches was a Brit. Everything
Wacom-related, driver and userspace, refers to it as eraser. Since this is a
hardware-property that effectively overrides kernel data we stick with the
kernel terminology, in libinput we use American English to prevent the 'u'
key from wearing out.
Cheers,
Peter
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 6/8] tablet: support tool-specific pressure offsets
If a tool wears out, it may have a pre-loaded pressure offset. In that case,
even when the tool is not physically in contact with the tablet surface it
will send pressure events.
The X.Org wacom driver has automatic pressure preload detection, but it is
unreliable. A quick tap can trigger the detection, making the pen unusable
(see xf86-input-wacom-0.23.0-43-g10cc765).
Since this is a hardware-specific property, add a new udev property with the
prefix TABLET_TOOL_PRESSURE_OFFSET_ and let it be set system-wide through the
hwdb or some other process. Use the value of this property to offset any
incoming pressure values and scale into the original normalized axis range.
Signed-off-by: Peter Hutterer
---
doc/device-configuration-via-udev.dox| 4 +
doc/tablet-support.dox | 30 ++
src/evdev-tablet.c | 71 +-
src/libinput-private.h | 2 +
test/litest-device-wacom-intuos-tablet.c | 12 +++
test/tablet.c| 155 ++-
6 files changed, 270 insertions(+), 4 deletions(-)
diff --git a/doc/device-configuration-via-udev.dox
b/doc/device-configuration-via-udev.dox
index f615cc1..ba44e58 100644
--- a/doc/device-configuration-via-udev.dox
+++ b/doc/device-configuration-via-udev.dox
@@ -63,6 +63,10 @@ libinput_pointer_get_axis_source() for details.
POINTINGSTICK_CONST_ACCEL
A constant (linear) acceleration factor to apply to pointingstick deltas
to normalize them.
+TABLET_TOOL_PRESSURE_OFFSET_*
+Specifies the pressure offset in device coordinates for the tool whose
+name is given as part of the property name. See @ref tablet-pressure-offset
+for details.
LIBINPUT_MODEL_*
This prefix is reserved as private API, do not use. See @ref
model_specific_configuration for details.
diff --git a/doc/tablet-support.dox b/doc/tablet-support.dox
index 24d08d2..27f970a 100644
--- a/doc/tablet-support.dox
+++ b/doc/tablet-support.dox
@@ -92,4 +92,34 @@ if (value < min) {
}
@endcode
+@section tablet-pressure-offset Pressure offset on worn-out tools
+
+When a tool is used for an extended period it can wear down physically. A
+worn-down tool may never return a zero pressure value. Even when hovering
+above the surface, the pressure value returned by the tool is nonzero,
+creating a fake surface touch and making interaction with the tablet less
+predictable.
+
+libinput allows for a static configuration to be applied to negate this
+effect. If set, the TABLET_TOOL_PRESSURE_OFFSET_... udev property
+specifies the tool-specific offset to be applied to any pressure
+calculation. The calculation is done transparent to the caller.
+
+The udev property name contains the type and serial number of the tool, the
+value is the offset in device coordinate range. The type of the tool is the
+string as defined in linux/input.h without the BTN_TOOL_ prefix (e.g. "PEN",
+"RUBBER", ...). The serial number is the uppercase hexadecimal serial number
+without the 0x prefix.
+
+For example, if a tool with the serial number ab1234 has a pressure offset
+of 20 on the pen and 30 on the eraser tool, the properties should be
+
+@code
+TABLET_TOOL_PRESSURE_OFFSET_PEN_AB1234=20
+TABLET_TOOL_PRESSURE_OFFSET_RUBBER_AB1234=30
+@endcode
+
+Pressure offsets are not available on @ref LIBINPUT_TABLET_TOOL_TYPE_MOUSE
+and @ref LIBINPUT_TABLET_TOOL_TYPE_LENS tools.
+
*/
diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
index e9473e8..d3ec1da 100644
--- a/src/evdev-tablet.c
+++ b/src/evdev-tablet.c
@@ -202,7 +202,7 @@ tablet_update_tool(struct tablet_dispatch *tablet,
}
static inline double
-normalize_pressure_dist_slider(const struct input_absinfo *absinfo)
+normalize_dist_slider(const struct input_absinfo *absinfo)
{
double range = absinfo->maximum - absinfo->minimum;
double value = (absinfo->value - absinfo->minimum) / range;
@@ -211,6 +211,17 @@ normalize_pressure_dist_slider(const struct input_absinfo
*absinfo)
}
static inline double
+normalize_pressure(const struct input_absinfo *absinfo,
+ struct libinput_tablet_tool *tool)
+{
+ double range = absinfo->maximum - absinfo->minimum;
+ int offset_val = absinfo->value - tool->pressure_offset;
+ double value = (offset_val - absinfo->minimum) / range;
+
+ return value;
+}
+
+static inline double
normalize_tilt(const struct input_absinfo *absinfo)
{
double range = absinfo->maximum - absinfo->minimum;
@@ -368,10 +379,12 @@ tablet_check_notify_axes(struct tablet_dispatch *tablet,
else
tablet->axes[a] = absinfo->value;
break;
- case LIBINPUT_TABLET_TOOL_AXIS_DISTANCE:
case LIBINPUT_TABLET_TOOL_AXIS_PRESSURE:
+ tablet->axes[a] = normalize_pressure(absinfo, tool);
+ break;
+ case LIBINPUT_TABLET_TOOL_AXIS_DISTANCE:
case LIBIN
