On Mon, Mar 26, 2018 at 2:36 AM, Pekka Paalanen wrote:
> On Fri, 23 Mar 2018 09:33:10 -0700
> Jason Gerecke wrote:
>
>> Nice! Do you think its reasonable to extend the allowed use of this
>> protocol to other kinds of direct-input devices? I don't see anything
&
Nice! Do you think its reasonable to extend the allowed use of this
protocol to other kinds of direct-input devices? I don't see anything
which would prevent this protocol from working equally well to
calibrate the pen input for a tablet PC or Cintiq for example. The
compositor would need to obviou
causes window contents to scroll down and button 5 to be
reported to xwayland clients. The xfreerdp client does not seem to be
the cause of this since scrolling works correctly when connecting to
a Windows host.
Signed-off-by: Jason Gerecke
---
libweston/compositor-rdp.c | 2 +-
1 file changed, 1
On Thu, Nov 9, 2017 at 2:19 PM, Jason Gerecke wrote:
> On Tue, Nov 7, 2017 at 2:37 PM, Peter Hutterer
> wrote:
>> On Tue, Nov 07, 2017 at 11:09:44AM -0800, Jason Gerecke wrote:
>>> BTN_STYLUS3 has been introduced by the Linux 4.15 kernel to report the
>>> status
On Tue, Dec 19, 2017 at 12:33 AM, Maniraj Devadoss
wrote:
> Hi Jason,
>
> I found the root cause for the backtrace you shared
> https://lists.freedesktop.org/archives/wayland-devel/2017-November/035964.html
>
> The issue is that the tablet tool's surface and view is not
> set as mapped in tablet_t
On Thu, Nov 23, 2017 at 2:17 AM, Maniraj Devadoss
wrote:
> Hi,
>
> The previous posting of this series was at
> https://lists.freedesktop.org/archives/wayland-devel/2017-October/035534.html
>
> which had some issues when Jason Gerecke tried to test
> it.
> https://lists.
;
> -Original Message-
> From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On
> Behalf Of Jason Gerecke
> Sent: Tuesday, November 7, 2017 8:52 AM
> To: Bastian Farkas
> Cc: wayland-devel@lists.freedesktop.org
> Subject: Re: [PATCH weston 00/16] Tabl
On Tue, Nov 7, 2017 at 2:37 PM, Peter Hutterer wrote:
> On Tue, Nov 07, 2017 at 11:09:44AM -0800, Jason Gerecke wrote:
>> BTN_STYLUS3 has been introduced by the Linux 4.15 kernel to report the
>> status of the third button present on Wacom's new "Pro Pen 3D" stylus.
BTN_STYLUS3 has been introduced by the Linux 4.15 kernel to report the
status of the third button present on Wacom's new "Pro Pen 3D" stylus.
Treat this button like xf86-input-wacom and send a button 8 event
("navigate back") when received from Wayland.
Signed-off-by
On Wed, Oct 25, 2017 at 4:12 AM, Bastian Farkas wrote:
> Hi,
>
> with Peter Hutterers permission I modified an outdated patchset from him that
> adds support for tablet devices to the weston compositor. Several minor
> changes were needed to get the patches working with a recent weston version.
; +
> + litest_button_click(dev, code, 1);
> + litest_button_click(dev, code, 0);
> + libinput_dispatch(li);
> +
> + litest_assert_pad_button_event(li,
> + i,
> +
On Thu, Sep 21, 2017 at 7:00 AM, Matt Porter wrote:
> On Thu, Sep 21, 2017 at 10:59:08AM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 19-09-17 18:41, Matt Porter wrote:
>> > The Chalkboard Electronics HID Touchscreen is classified as
>> > a tablet device by systemd udev because it has BTN_TOOL_PEN
ode = ABS_MISC, .value = 0 },
> + { .type = EV_SYN, .code = SYN_REPORT, .value = 0 },
> + { .type = -1, .code = -1 },
> +} ;
> +
> +static struct litest_device_interface interface = {
> + .touch_down_events = down,
> + .touch_move_events = move,
> +
asserting.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=100057
Surely you meant https://bugs.freedesktop.org/show_bug.cgi?id=101853
Aside from that, seems like a reasonable workaround until the pony can
either be taught a second trick or swapped out for a more capable
animal.
Reviewed-by
On Mon, Dec 19, 2016 at 7:04 AM, James Feeney wrote:
> On 12/19/2016 03:04 AM, Pekka Paalanen wrote:
>> We very deliberately avoid defining any "standard" Wayland interfaces
>> for configuring a compositor, because every compositor is different.
>> With X11, you had the one single X server impleme
On 11/03/2016 06:46 PM, Peter Hutterer wrote:
> We're using sequentially numbered buttons for the pad because actual tablets
> are quite varied in how the present buttons (BTN_A, BTN_0, etc.). For this
> reason, libinput numbers pad buttons sequentially.
>
> Let's do the same for tablet tools. Unf
On 10/27/2016 10:22 PM, Peter Hutterer wrote:
> Time to discuss graphics tablet support in weston: I had a patchset for some
> earlier version of the tablet protocol, since then we've added a few bits
> and bobs, including the mode switching support.
>
> Short story behind this email is: I serious
it is set.
>
> Signed-off-by: Peter Hutterer
The revised series looks good to me -- thanks again :)
Reviewed-by: Jason Gerecke
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 thr
The first 5 patches look fine, but I have a few questions about this
one, especially in the unit tests:
On 08/21/2016 11:14 PM, Peter Hutterer wrote:
> So far we've relied on the wacom kernel module to do touch arbitration for us
> but that won't be the case in upcoming kernels. Implement touch ar
t;
> -
> - /* Same as above, but don't bother checking the serial number */
> - list_for_each(t, tool_list, link) {
> + * list
> + * Same as above, but don't bother checking the serial number
> + */
> + list_for_each(t
On 08/17/2016 10:20 PM, Peter Hutterer wrote:
> If the kernel does not send the MSC_SERIAL information with every event, we
> end up creating a tool with a serial of 0. When the MSC_SERIAL comes in
> later for this tool libinput will think it's a new tool. On proximity out of
> that new tool we sen
ps, effectively sets of button/ring/strip
> configurations. Those groups may have multiple modes each, so that
> users/clients may map several actions to a single element.
>
> Signed-off-by: Carlos Garnacho
> Signed-off-by: Peter Hutterer
> Reviewed-by: Jason Gerecke
> ---
>
>>> client
>>>> to set a user-defined string to display for an OSD on the current mappings.
>>>> This request is available for buttons, rings and strips.
>>>>
>>>> Finally, the pad supports groups, effectively sets of button/ring/st
t; For the stylus-like devices leave the current accel, pointer acceleration on a
> stylus is hard to handle.
>
> This also adds the missing bits for actually using the speed factor set
> through the config interface.
>
> Signed-off-by: Peter Hutterer
Looks good to me --
Reviewed
n track to be
> in an upstream kernel I'll update the implementation, for now we go with
> this one.
>
> Cheers,
> Peter
Aside from the small comments on two of the patches, this looks good to
me. Testing also seems to look good aside from the not-yet-implemented
direct
On 06/14/2016 11:37 PM, Peter Hutterer wrote:
> Requires the newest libwacom. For distributions that want to ship libinput but
> don't have the new libwacom available: the actual minimum requirement is
> libwacom 0.17 but with that test cases will fail due to wrong button labelling
> for the EKR.
>
On 06/14/2016 11:37 PM, Peter Hutterer wrote:
> Move mode control to libinput. This reduces some flexibility on what we can do
> with modes but makes it a lot easier for anyone to implement modes correctly
> and have the LEDs apply appropriately, etc. Let's go with the option to make
> the 95% use-
On Sun, Jun 5, 2016 at 11:50 PM, Peter Hutterer
wrote:
> Signed-off-by: Peter Hutterer
> ---
> configure.ac | 2 +-
> src/Makefile.am | 1 +
> src/evdev-tablet-pad-leds.c | 621
> ++
> src/evdev-tablet-pad.c|
On Sun, Jun 5, 2016 at 11:50 PM, Peter Hutterer
wrote:
> Move mode control to libinput. This reduces some flexibility on what we can do
> with modes but makes it a lot easier for anyone to implement modes correctly
> and have the LEDs apply appropriately, etc. Let's go with the option to make
> th
On 05/17/2016 03:02 AM, Carlos Garnacho wrote:
> Hey :),
>
> On Tue, May 17, 2016 at 2:50 AM, Peter Hutterer
> wrote:
>> On Tue, May 17, 2016 at 01:30:03AM +0200, Carlos Garnacho wrote:
>>> Hey :),
>>>
>>> On Wed, May 11, 2016 at 4:51 AM, Peter Hutterer
>>> wrote:
From: Carlos Garnacho
>>>
ast time but
> rebased onto v2 and with a couple of small additions.
>
> Cheers,
> Peter
>
Aside from my minor comments, these look good to me :)
Reviewed-by: Jason Gerecke
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to s
On Tue, May 10, 2016 at 7:51 PM, Peter Hutterer
wrote:
> From: Carlos Garnacho
>
> The pad's interface is similar to the tool interface, a client is notified of
> the pad after the tablet_added event.
>
> The pad has three functionalities: buttons, rings and strips.
> Buttons are fairly straightf
On Tue, May 10, 2016 at 7:51 PM, Peter Hutterer
wrote:
> The initial approach was to allow one surface to be re-used between tools,
> seats and even used together as wl_pointer cursor surface. This has a few
> drawbacks, most of which are related to managing the surface correctly in the
> composit
cgi?id=95074
>
> And while we're at it, sneak in a test for pressure ranges too.
>
> Signed-off-by: Peter Hutterer
Looks good to me --
Reviewed-by: Jason Gerecke
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight)
On Thu, Apr 21, 2016 at 7:02 PM, Peter Hutterer
wrote:
> On Thu, Apr 21, 2016 at 05:46:24PM -0700, Jason Gerecke wrote:
>> On Mon, Apr 18, 2016 at 10:00 PM, Peter Hutterer
>> wrote:
>> > From: Carlos Garnacho
>> >
>> > The pad's interface is simi
On Mon, Apr 18, 2016 at 10:00 PM, Peter Hutterer
wrote:
> From: Carlos Garnacho
>
> The pad's interface is similar to the tool interface, a client is notified of
> the pad after the tablet_added event.
>
> The pad has three functionalities: buttons, rings and strips.
> Buttons are fairly straight
et_button() to the more explicitly named
> libinput_event_tablet_pad_get_button_number(). Just to drive the point home.
>
> Cheers,
> Peter
Just a few small issues highlighted in their respective patches (esp. in
patch 4), but nothing that I think is beyond a pre-push fixup.
Reviewed
On 04/10/2016 09:15 PM, Peter Hutterer wrote:
> This interface handles the buttons on the physical tablet itself, including
> the touch ring and the strip.
>
> A notable difference to other libinput interfaces here is that we do not use
> linux/input.h event codes for buttons. Instead, the buttons
On 04/10/2016 09:15 PM, Peter Hutterer wrote:
> Signed-off-by: Peter Hutterer
> ---
> Adjustments for the new API in 2/5
>
> src/Makefile.am| 1 +
> src/evdev-tablet-pad.c | 614
> +
> src/evdev-tablet-pad.h | 69 ++
> src/evdev.c
of fuzz isn't a huge issue but is still something that should
be fixed?
Reviewed-by: Jason Gerecke
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,/
On 03/08/2016 10:10 PM, Peter Hutterer wrote:
> Signed-off-by: Peter Hutterer
> Reviewed-by: Daniel Stone
> Reviewed-by: Jonas Ådahl
> ---
> Changes to v6:
> - a bunch of typos/grammar fixes
> - clarified the "down" event on enter
> - clarified the "up" event, specifically: the up event isn't se
A number of tiny fixes, and a couple of questions:
On 02/29/2016 04:09 PM, Peter Hutterer wrote:
> Signed-off-by: Peter Hutterer
> Reviewed-by: Daniel Stone
> ---
> Changes to v5:
> - remove leftover statement falsely claminig wp_tablet_tool.destroy requires
> a remove event first
>
> Makefi
nge_max"). You might
consider having the normalization only occur in the 'else' case so that
the 'if' can be written more straightforwardly:
double value;
const int WACOM_MAX_DEGREES = 64;
if ( /* can use resolution */ ) {
value = 180.0/M_PI * absinfo->value/absinfo->res
let_dispatch *tablet)
>values. The device has a 175 degree CCW hardware offset but since
> we use
>atan2 the effective offset is just 5 degrees.
>*/
> - x = tablet->axes.tilt.x;
> - y = tablet->axes.tilt.y;
> + x = -tabl
On Tue, Feb 2, 2016 at 1:12 PM, Bill Spitzak wrote:
>
>
> On Mon, Feb 1, 2016 at 6:38 PM, Jason Gerecke wrote:
>>
>>
>> Ultimately, the tilt information is almost universally used by
>> applications to set brush orientation. To do that, you have to use
>>
On Mon, Feb 1, 2016 at 4:55 PM, Peter Hutterer wrote:
> On Mon, Feb 01, 2016 at 04:12:24PM -0800, Jason Gerecke wrote:
>> On Sun, Jan 31, 2016 at 2:27 PM, Peter Hutterer
>> wrote:
>> > On Fri, Jan 29, 2016 at 11:40:44AM -0800, Jason Gerecke wrote:
>> >> On
On Sun, Jan 31, 2016 at 2:27 PM, Peter Hutterer
wrote:
> On Fri, Jan 29, 2016 at 11:40:44AM -0800, Jason Gerecke wrote:
>> On Thu, Jan 28, 2016 at 8:32 PM, Peter Hutterer
>> wrote:
>> > Signed-off-by: Peter Hutterer
>> > ---
>> > Changes to v2:
On Thu, Jan 28, 2016 at 8:32 PM, Peter Hutterer
wrote:
> Signed-off-by: Peter Hutterer
> ---
> Changes to v2:
> - renamed hwserial to hardware_serial
> - renamed to hwid event to a hardware_id_wacom. no-one else uses this ID
> type, so having a generic event with a wacom-specific type + enum is
acceleration is quite simple atm, it's a flat profile and the speed
> setting simply multiplies the vector. Can be extended later if need be.
>
> Cheers,
> Peter
Looks good! I don't see any obvious problems, though I'm still not
100% familiar with the codebase. For the s
ts,
> treating button events separately here doesn't get us any benefit.
>
> Signed-off-by: Peter Hutterer
Still not convinced about providing axis info in the tip and button
events, but its not my API to design :D
Acked-by: Jason Gerecke
Jason
---
Now instead of four in the eig
yay for
consistency!)
Reviewed-by: Jason Gerecke
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
>
> src/evdev-tablet.c | 4 ++--
&
Largely looks good, aside from a few comments. For the series:
Acked-by: Jason Gerecke
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
On Mon, Jan 4, 2016 at 5:21 PM, Peter Hutterer wrote:
> When we're only dealing with BTN_TOUCH we can make the tip event independent
> of the axis event. Now that we handle pressure thresholds to trigger tip state
> this does not work, we'd have to send an axis event with the new pressure and
> th
'On Mon, Jan 4, 2016 at 5:21 PM, Peter Hutterer
wrote:
> On tablets with ABS_PRESSURE use a pressure value to determine tip state, not
> BTN_TOUCH. This enables us (down the road) to have device-specific pressure
> thresholds. For now we use a 5% default for all devices.
>
> The threshold is a ran
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:
>> >> O
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
>> >
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 d
On Fri, Nov 6, 2015 at 4:11 PM, Bill Spitzak wrote:
> Having read this more carefully, the cursor scheme absolutely will not work.
>
> The main problem is that the client may want to choose a cursor for a tool
> based on the location at which it came into proximity. It cannot set this
> cursor unt
On Thu, Nov 5, 2015 at 8:55 PM, Peter Hutterer wrote:
> Signed-off-by: Peter Hutterer
The weston patches are going to have to be modified to work with this
API change, but otherwise...
For the series:
Reviewed-by: Jason Gerecke
Jason
---
Now instead of four in the eights place /
you’ve
released or the tool leaves the
> + proximity of the tablet.
> +
> +
> +
> +
> +
> + Sent whenever the tablet tool comes in contact with the surface of the
> + tablet. If the tablet tool moves out of a region while in contact with
> +
On Thu, Nov 5, 2015 at 8:31 PM, Peter Hutterer wrote:
>
> This set adds support for graphics tablets to weston. It's not fully
> complete, there are a couple of fixmes in it but the patchset is getting a
> bit unwieldly. And there are some discussions on how to do things anyway.
>
> Note: This nee
Signed-off-by: Jason Gerecke
---
doc/absolute-axes.dox | 2 +-
doc/faqs.dox | 2 +-
doc/gestures.dox | 2 +-
doc/palm-detection.dox | 4 ++--
doc/reporting-bugs.dox | 2 +-
doc/seats.dox | 4 ++--
doc/tapping.dox| 2 +-
doc/tools.dox | 4 ++--
doc
On 8/17/2015 7:21 PM, Peter Hutterer wrote:
> On Mon, Aug 17, 2015 at 05:29:14PM -0700, Jason Gerecke wrote:
>> Similar to the issue mentioned in the commit message of 2365f7d, libwacom
>> assigns both ID_INPUT_TABLET and ID_INPUT_TOUCHSCREEN to touchscreens like
>> the Cin
Similar to the issue mentioned in the commit message of 2365f7d, libwacom
assigns both ID_INPUT_TABLET and ID_INPUT_TOUCHSCREEN to touchscreens like
the Cintiq 24HDT. This patch ensures that neither touchpads nor touchscreens
will accidentally be handled by the tablet code.
Signed-off-by: Jason
alue is reset to 0 if five or more fingers are physically present (due
to the behavior of 'tp_unhover_touches' mentioned in the bug report).
That said, the patch *does* prevent the error messages from appearing,
so at the very least:
Tested-by: Jason Gerecke
Jason
---
Now instead of
have some
trouble with the 3 cm heuristic (about half the time I try to scroll,
its interpreted as a pinch) but I'd probably get used to it after a
little use.
Acked-by: Jason Gerecke
[1]: https://bugs.freedesktop.org/show_bug.cgi?id=89800
Jason
---
Now instead of four in the eights place /
y
Signed-off-by: Jason Gerecke
---
For Peter's tablet-support branch.
tools/event-debug.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/event-debug.c b/tools/event-debug.c
index d2ac415..e8e49cd 100644
--- a/tools/event-debug.c
+++ b/tools/event-debug.c
@@ -480,6 +
Devices like the Cintiq 24HDT are marked with both ID_INPUT_TABLET and
ID_INPUT_TOUCHSCREEN in udev. Be sure that we don't try to use such a
device as a tablet.
Signed-off-by: Jason Gerecke
---
For Peter's tablet-support branch.
src/evdev.c | 10 +-
1 file changed, 5 insert
Did some practical testing of these patches and noticed two issues with
the touchstrips:
On 3/17/2015 11:58 PM, Peter Hutterer wrote:
From: Benjamin Tissoires
Same approach as evdev-tablet (started as copy/paste), with axis and buttons
adjusted. Wacom's handling of pad devices requires a lot
David's already asked the API questions that popped in my head, so I'll
just wait for feedback on his thread. As far as this patch goes, things
look pretty good though there are two comments:
On 3/17/2015 11:58 PM, Peter Hutterer wrote:
From: Benjamin Tissoires
Same approach as evdev-tablet
On 2/23/2015 10:21 PM, Peter Hutterer wrote:
This is a v2 of the patchset here
http://lists.freedesktop.org/archives/wayland-devel/2015-February/020036.html
but reshuffled, rebased and a couple of things merged in. Notable:
libinput now uses libwacom to get tool/tablet information. This is compl
On 2/23/2015 10:21 PM, Peter Hutterer wrote:
This doesn't really have an effect, since we don't set the per-tool axes
correctly yet.
Signed-off-by: Peter Hutterer
---
tools/event-debug.c | 106 +++-
1 file changed, 56 insertions(+), 50 deletio
On 2/23/2015 10:21 PM, Peter Hutterer wrote:
Signed-off-by: Peter Hutterer
---
src/evdev-tablet.c | 35 +++-
src/evdev-tablet.h | 6
src/libinput.h | 3 +-
test/tablet.c | 95 ++
4 files changed, 130 inser
On 2/23/2015 10:21 PM, Peter Hutterer wrote:
Needs to be calculated from the x/y tilt values, the mouse has a fixed offset
of 175 degrees counterclockwise.
Signed-off-by: Peter Hutterer
---
src/evdev-tablet.c | 88 +-
src/libinput-private.
On 2/23/2015 10:21 PM, Peter Hutterer wrote:
ABS_THROTTLE:
Tablets still advertise this axis but the mouse itself isn't available
anymore. The Pad sends the second wheel as ABS_THROTTLE but that's a
task for the buttonset interface. Explanation of what the throttle
On Wed, Feb 18, 2015 at 5:29 PM, Peter Hutterer
wrote:
> On Wed, Feb 18, 2015 at 01:57:17PM -0800, Jason Gerecke wrote:
>>
>> On 2/16/2015 9:11 PM, Peter Hutterer wrote:
>> >On Mon, Feb 16, 2015 at 08:13:01AM +0100, Hans de Goede wrote:
>> >>Hi,
>> >&
On 2/17/2015 9:45 PM, Peter Hutterer wrote:
This patchset adds the remaining tools to the tablet branch (at least for
Wacom tools). The notable additions are:
* rotation support for mouse/lens cursor
* rotation support for the artpen
* 'wheel' support for the airbrush
* correct per-tool capabili
On 2/16/2015 9:11 PM, Peter Hutterer wrote:
On Mon, Feb 16, 2015 at 08:13:01AM +0100, Hans de Goede wrote:
Hi,
On 16-02-15 04:50, Peter Hutterer wrote:
ok, I've played around with the ideas in this thread and discussed it with
Benjamin this morning. Short summary: I think we should go with
ll" is used more). And Z has the advantage
>>> that
>>> it also implies that counter-clockwise is positive.
>>
>>
>> my main issue with Z is that it's not immediately clear what it refers to
>> in
>> the context of a tablet. x/y is
Signed-off-by: Jason Gerecke
Acked-by: Peter Hutterer
---
test/litest-wacom-intuos-tablet.c | 3 +++
test/tablet.c | 41 +--
2 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/test/litest-wacom-intuos-tablet.c
b/test/litest
Some Wacom tablets can report the rotation of the pen about its barrel
in the ABS_Z axis. Report this via LIBINPUT_TABLET_AXIS_TWIST.
Signed-off-by: Jason Gerecke
Acked-by: Peter Hutterer
---
src/evdev-tablet.c | 6 ++
src/evdev-tablet.h | 6 ++
src/libinput.c | 1 +
src/libinput.h
Changes the names to reflect the functionality, not the use case. Also
defines one in terms of the other so that we aren't repeating ourselves.
Signed-off-by: Jason Gerecke
Acked-by: Peter Hutterer
---
src/evdev-tablet.c | 15 ++-
1 file changed, 6 insertions(+), 9 dele
The presence of a "+1" in the range calculation prevents the
normalization functions from returning a value of "1.0" when
absinfo->value has reached its maximum.
Signed-off-by: Jason Gerecke
---
src/evdev-tablet.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
We need to *subtract*, not *add* the minimum to determine the
range-effective value. For example: if (min, current, max) is
(100, 100, 1000) then the normalized value would be 0.0, not 0.2.
Signed-off-by: Jason Gerecke
---
This patch should be applied to the 'tablet-support' branch,
On Aug 19, 2014 5:04 AM, "Pekka Paalanen" wrote:
>
> On Wed, 6 Aug 2014 19:07:50 -0400
> Stephen Chandler Paul wrote:
>
> > Hi! As some of you have been aware, I have been working on implementing
tablet
> > ssupport in libinput, the wayland protocol and weston. This patchset
adds basic
> > table
On Sat, Aug 2, 2014 at 12:31 PM, Lyude wrote:
> I'm sorry I took so long to reply to this! I only just found this e-mail
> while I was cleaning my inbox up.
>
> On Wed, 2014-07-30 at 17:33 -0700, Jason Gerecke wrote:
>> On Tue, Jul 29, 2014 at 12:44 PM, Lyude wrote:
>&g
less you happen to be on one of those weird architectures).
Should I just make a patch for this already? :P
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
On Mon, Jul 28, 2014 at 10:54 AM, Bill Spitzak wrote:
> On 07/28/2014 09:41 AM, Jason Gerecke wrote:
>
>> Normalizing the data is fine, but the resolution data needs to be
>> available somewhere as well. The GTK+ API doesn't require anything
>> more than the former,
On Wed, Jul 16, 2014 at 5:08 PM, Lyude wrote:
> On Mon, 2014-07-14 at 13:25 -0700, Jason Gerecke wrote:
>> On Sun, Jul 13, 2014 at 12:17 PM, Lyude wrote:
>> >wl_tablet specifications
>> > Version 2
>>
On Sun, Jul 13, 2014 at 12:17 PM, Lyude wrote:
>wl_tablet specifications
> Version 2
>
> General notes:
> - Many of the axis values in this are normalized to either 0-65535 or
> (-65535)-65535. I would leave the axis values as-is sinc
On Wed, Jul 2, 2014 at 3:33 PM, Fabrice Rey wrote:
>> "The question is: what action triggers it to make this ring of icons
>> appear?"
> A global shortkey (and yes I know it's not yet possible on Wayland, that's
> another problem on its own).
>
>> "What's the application doing? Does it have keyboa
On Mon, Jun 30, 2014 at 3:46 AM, Peter Hutterer
wrote:
> On 30/06/2014 20:23 , Pekka Paalanen wrote:
>>
>> On Mon, 30 Jun 2014 09:33:15 +0300
>> Pekka Paalanen wrote:
>>
>>> On Mon, 30 Jun 2014 11:08:35 +1000
>>> Peter Hutterer wrote:
>>>
On Sat, Jun 28, 2014 at 12:41:33PM +0300, Pekka Paal
On Thu, Jun 26, 2014 at 8:02 PM, Peter Hutterer
wrote:
> Those three are the ones that matter for logging or device identification in
> callers, so let's provide them.
>
> Signed-off-by: Peter Hutterer
Have you thought about how to handle identification for non-USB
devices? We're starting to see
On Wed, Jun 25, 2014 at 5:50 PM, Peter Hutterer
wrote:
> Replying to three emails at once here to keep the thread a bit more
> managable.
>
> On Wed, Jun 25, 2014 at 01:38:22PM -0700, Jason Gerecke wrote:
>> On Wed, Jun 25, 2014 at 12:38 AM, Lyude wrote:
>> > On Wed
On Thu, Jun 26, 2014 at 12:12 AM, Peter Hutterer
wrote:
> On Thu, Jun 26, 2014 at 09:48:37AM +0300, Pekka Paalanen wrote:
>> Hi,
>>
>> it seems you forgot to reply-to-all, so I have re-added everyone and
>> not trimmed the quotation.
>>
>> On Wed, 25 Jun 2014 18:37:08 -0400
>> Lyude wrote:
>>
>>
On Wed, Jun 25, 2014 at 12:38 AM, Lyude wrote:
> On Wed, 2014-06-25 at 11:06 +0400, Dmitry Kazakov wrote:
>> Hi, all!
>>
>>
>> I am a developer from Krita painting application team. We recently did
>> quite much work on incorporating better tablet support in Krita. I
>> have several comments about
On Thu, May 29, 2014 at 11:45 PM, Daniel Stone wrote:
> On 29 May 2014 18:54, Jason Gerecke wrote:
>>
>> If that's the case though, I have to ask -- *why* on Earth is
>> 'li_fixed_t' even being considered as libinput's output type? I know
>> I
On Wed, May 28, 2014 at 6:39 PM, Peter Hutterer
wrote:
> On Wed, May 28, 2014 at 10:23:00AM -0700, Jason Gerecke wrote:
>> On Tue, May 27, 2014 at 8:32 PM, Chandler Paul wrote:
>> > On Wed, 2014-05-28 at 12:48 +1000, Peter Hutterer wrote:
>> >> On Tue, May 27, 2
On Tue, May 27, 2014 at 8:32 PM, Chandler Paul wrote:
> On Wed, 2014-05-28 at 12:48 +1000, Peter Hutterer wrote:
>> On Tue, May 27, 2014 at 03:40:07PM -0700, Jason Gerecke wrote:
>> > On Tue, May 27, 2014 at 3:20 PM, Peter Hutterer
>> > wrote:
>> > > O
On Tue, May 27, 2014 at 3:52 PM, Peter Hutterer
wrote:
> On Tue, May 27, 2014 at 01:11:31PM -0700, Jason Gerecke wrote:
>> I've been away from my computer for most of the (long) weekend up
>> here, so apologies for being a bit quiet :)
>>
>>
>> On Sun, M
1 - 100 of 104 matches
Mail list logo