The following commit has been merged into the locking/core branch of tip:
Commit-ID: 864b435514b286c0be2a38a02f487aa28d990ef8
Gitweb:
https://git.kernel.org/tip/864b435514b286c0be2a38a02f487aa28d990ef8
Author:Jason Gerecke
AuthorDate:Thu, 11 Feb 2021 13:48:48 -08:00
The following commit has been merged into the locking/core branch of tip:
Commit-ID: 566a9522381495d27b596ee3bdc9578ba02a895d
Gitweb:
https://git.kernel.org/tip/566a9522381495d27b596ee3bdc9578ba02a895d
Author:Jason Gerecke
AuthorDate:Thu, 11 Feb 2021 13:48:48 -08:00
On Fri, Feb 12, 2021 at 7:27 AM Peter Zijlstra wrote:
>
> On Fri, Feb 12, 2021 at 09:40:59AM -0500, Steven Rostedt wrote:
> > On Thu, 11 Feb 2021 13:48:48 -0800
> > Jason Gerecke wrote:
> >
> > > When compiling an external kernel module with `-O0` or `-O1`, t
hese lower optimization levels prevent GCC from detecting
that the key/branch arguments can be treated as constants and used as
immediate operands. To work around this, explicitly add the `const` label.
Signed-off-by: Jason Gerecke
Cc: Steven Rostedt
Cc: Ard Biesheuvel
---
Marked RFC since I'm no
My apologies. I copied the wrong commit SHA when generating this
commit. Commit cd47de45b855 is the reference to this commit in our
input-wacom tree, not upstream. The correct Fixes tag should indeed
be:
Fixes: 912c6aa67ad4 ("HID: wacom: Add 2nd gen Intuos Pro Small support")
Thanks,
Jason
---
No
On Mon, Aug 12, 2019 at 9:29 AM Benjamin Tissoires
wrote:
>
> This is a common pattern in the HID drivers to reset the drvdata.
> However, this is actually already handled by driver core, so there
> is no need to do it manually.
>
> Signed-off-by: Benjamin Tissoires
Acked
, 2017 at 10:50 AM, Jason Gerecke wrote:
> Looks like this might also be needed for the MobileStudio Pro...
>
> https://bugzilla.kernel.org/show_bug.cgi?id=197991
>
> Jason
> ---
> Now instead of four in the eights place /
> you’ve got three, ‘Cause you added one /
> (Th
Looks like this might also be needed for the MobileStudio Pro...
https://bugzilla.kernel.org/show_bug.cgi?id=197991
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
7;t anything
with a descriptor quite like it. That said, there's a good chance that
we'll see something similar in the future...
I'm still not entirely happy with the one-off approach, but I'll but
my stamp of approval on it. We can work out a more generic way to
detect and configure these dual-resolution devices going forward :)
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
On November 3, 2017 10:29:47 AM PDT, Benjamin Tissoires
wrote:
>The Dell Canvas exports 2 collections for the Pen part. The only
>difference between the 2 is that the default one has half the
>resolution
>of the second one.
>
>The Windows driver switches the tablet into the second mode, so we
>sh
M_INTUOS_RES };
>> +static const struct wacom_features wacom_features_0x37B =
>> + { "One by Wacom CTL672", 21648, 13530, 2047, 63,
Replace "CTL672" in name with "M". Resolution should be 21600 x 13500,
not 21648 x 13530.
>> + BAMBOO_P
On Fri, Jul 28, 2017 at 7:29 AM, Arnd Bergmann wrote:
> On Fri, Jul 28, 2017 at 4:24 PM, Jason Gerecke wrote:
>> On Fri, Jul 28, 2017 at 7:18 AM, Arnd Bergmann wrote:
>>> On Fri, Jul 28, 2017 at 4:07 PM, Jason Gerecke wrote:
>
>>> #ifdef CONFIG_USB_HID
>>&
On Fri, Jul 28, 2017 at 7:18 AM, Arnd Bergmann wrote:
> On Fri, Jul 28, 2017 at 4:07 PM, Jason Gerecke wrote:
>> On July 28, 2017 6:18:00 AM PDT, Arnd Bergmann wrote:
>>>The driver has gained a compile-time dependency that we should
>>>express in Kconf
On July 28, 2017 6:18:00 AM PDT, Arnd Bergmann wrote:
>The driver has gained a compile-time dependency that we should
>express in Kconfig to avoid this link error:
>
Would conditional compilation be an acceptable alternative to adding a
dependency? The USB_HID code is only used to check if the d
Going through old mail and noticed that these three patches seem to
have been overlooked (at least, I don't see them in Jiri's
branches...). For the set:
Reviewed-by: Jason Gerecke
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That
Came across these and noticed that it doesn't appear anything has
happened with them. The set 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) to the two, /
But you can’t
ded be a way to allow
new hardware to work with the hid-generic driver.
Jason Gerecke, Linux Software Engineer
Wacom Technology Corporation
tel: 360-896-9833 ext. 229 (direct) / fax: 360-896-9724
http://www.wacom.com
On 02/21/2017 01:03 PM, Jiri Kosina wrote:
> On Tue, 21 Feb 2017, Benjami
Patches 1/3 look reasonable to me, though I've not run into the bugs
they aim to fix. For those:
Acked-by: Jason Gerecke
As for patch 4, I have some additional reservations about hiding the
message... We can discuss that further in its thread.
Jason
---
Now instead of four in the eights
I'm not super comfortable with hiding this error. If the tablet reacts
appropriately, I wouldn't think we'd get an EPIPE. Although its not
fatal, it still might be a symptom of something deeper...
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That i
On 11/10/2016 11:25 AM, Dan Carpenter wrote:
> This is trying to clear the lower 32 bits but the type is wrong so it
> clears everything.
>
> Signed-off-by: Dan Carpenter
>
Reviewed-by: Jason Gerecke
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Caus
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 Sun, Nov 29, 2015 at 2:29 AM, Ioan-Adrian Ratiu wrote:
> On Fri, 20 Nov 2015 22
ke I forgot to update this comment to say
WACOM_DEVICETYPE_TOUCH. Mind fixing that in this patch since you're here
anyway?
Otherwise, looks good :)
Reviewed-by: Jason Gerecke
--
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to
tablets seem to have a similar vendor-defined usage that we can
trigger on.
Signed-off-by: Jason Gerecke
---
drivers/hid/wacom_sys.c | 23 +--
drivers/hid/wacom_wac.c | 8 +---
drivers/hid/wacom_wac.h | 6 +-
3 files changed, 23 insertions(+), 14 deletions(-)
diff
priori guarantee that it is a tablet or touchpad.
If the device_type is still uninitialized for a HID_GENERIC device then
we assume that it isn't something the driver can work with and so fail
the probe.
Signed-off-by: Jason Gerecke
---
drivers/hid/wacom_sys.c | 8 +++-
1 file chang
l"). This patch
updates the logic so that no suffix will be added to the device name if
the device type is unknown.
Signed-off-by: Jason Gerecke
---
drivers/hid/wacom_sys.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/hid/wacom_sys.c b/drivers/h
To determine if a touch is present in the single-touch case, we can
simply check if the BTN_TOUCH key is active or not. This will work for
both HID_GENERIC and other device types.
Signed-off-by: Jason Gerecke
---
drivers/hid/wacom_wac.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions
On 3/16/2015 2:04 PM, Benjamin Tissoires wrote:
On Mar 16 2015 or thereabouts, Jason Gerecke wrote:
On 3/16/2015 12:27 PM, Benjamin Tissoires wrote:
On Mar 16 2015 or thereabouts, Jason Gerecke wrote:
On 3/16/2015 7:50 AM, Jiri Kosina wrote:
On Thu, 5 Mar 2015, Benjamin Tissoires wrote:
If
On 3/16/2015 2:04 PM, Benjamin Tissoires wrote:
On Mar 16 2015 or thereabouts, Jason Gerecke wrote:
On 3/16/2015 12:27 PM, Benjamin Tissoires wrote:
On Mar 16 2015 or thereabouts, Jason Gerecke wrote:
On 3/16/2015 7:50 AM, Jiri Kosina wrote:
On Thu, 5 Mar 2015, Benjamin Tissoires wrote:
If
On 3/16/2015 12:27 PM, Benjamin Tissoires wrote:
On Mar 16 2015 or thereabouts, Jason Gerecke wrote:
On 3/16/2015 7:50 AM, Jiri Kosina wrote:
On Thu, 5 Mar 2015, Benjamin Tissoires wrote:
If noone listens to the input device when a tool comes in proximity,
the tablet does not send the in
ficult (e.g. for debugging),
but in the typical case where X is started shortly after boot and
hotplugs devices as soon as they're available it shouldn't pose a
problem. If Benjamin has any ideas I'd like to hear them, but in the
meantime I'm comfortable seeing this go upstream
On 3/3/2015 9:20 AM, Benjamin Tissoires wrote:
If noone listens to the input device when a tool comes in proximity,
the tablet does not send the in-prox event when a client becomes available.
That means that no events will be sent until the tool is taken out of
proximity.
In this situation, ask
appear to have a
HD_DG_PEN physical collection, so I also don't see any potential for
regression. For both patches:
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 ta
On Wed, Oct 8, 2014 at 5:28 PM, Dmitry Torokhov
wrote:
> On Wed, Oct 08, 2014 at 05:24:32PM -0700, Jason Gerecke wrote:
>> On Wed, Oct 8, 2014 at 2:40 PM, Dmitry Torokhov
>> wrote:
>> > On Wed, Oct 08, 2014 at 11:25:42AM -0700, Jason Gerecke wrote:
>> >> Repe
On Wed, Oct 8, 2014 at 2:40 PM, Dmitry Torokhov
wrote:
> On Wed, Oct 08, 2014 at 11:25:42AM -0700, Jason Gerecke wrote:
>> Repeated connect/disconnect cycles under GNOME can trigger an occasional
>> OOPS from within e.g. wacom_led_select_store, presumably due to a timing
>>
Repeated connect/disconnect cycles under GNOME can trigger an occasional
OOPS from within e.g. wacom_led_select_store, presumably due to a timing
issue where userspace begins setting a value immediately before the
device disconnects and our shared data is whisked away.
Signed-off-by: Jason
Repeated connect/disconnect cycles under GNOME can trigger an occasional
OOPS from within e.g. wacom_led_select_store, presumably due to a timing
issue where userspace begins setting a value immediately before the
device disconnects and our shared data is whisked away.
Signed-off-by: Jason
On Tue, Sep 30, 2014 at 10:27 AM, Benjamin Tissoires
wrote:
> On Sep 26 2014 or thereabouts, Jason Gerecke wrote:
>> On Fri, Sep 26, 2014 at 4:03 AM, Jiri Kosina wrote:
>> > On Tue, 23 Sep 2014, Benjamin Tissoires wrote:
>> >
>> >> Hi guys,
>> >
On Fri, Sep 26, 2014 at 4:03 AM, Jiri Kosina wrote:
> On Tue, 23 Sep 2014, Benjamin Tissoires wrote:
>
>> Hi guys,
>>
>> So, this patch series aims at supporting natively any future HID compliant
>> wacom
>> tablet. Those found on the various laptops (ISDv4/5) already are HID
>> compliant
>> and
and MO
>
> drivers/input/tablet/wacom.h | 2 +
> drivers/input/tablet/wacom_sys.c | 63 +++-
> drivers/input/tablet/wacom_wac.c | 328
> ++++---
> drivers/input/tablet/wacom_wac.h | 2 +
> 4 files changed, 259 insertions(+), 136 delet
On Wed, Jul 2, 2014 at 4:33 PM, Jason Gerecke wrote:
> On Mon, Jun 30, 2014 at 2:26 PM, Benjamin Tissoires
> wrote:
>> Hi guys,
>>
>> this patch series is a cleanup for the Wacom USB driver.
>>
>> I started working on this topic when I saw patches floating
On Mon, Jun 30, 2014 at 2:26 PM, Benjamin Tissoires
wrote:
> This removes an USB dependency and is more accurate: the computed pktlen
> is the actual maximum size of the reports forwarded by the device.
>
> Given that the pktlen is correctly computed/validated, we can store it now
> in the feature
On Mon, Jun 23, 2014 at 1:57 PM, Benjamin Tissoires
wrote:
> Currently, the pad events are sent through the stylus input device
> for the Intuos/Cintiqs, and through the touch input device for the
> Bamboos.
>
> To differentiate the buttons pressed on the pad from the ones pressed
> on the stylus,
On Mon, Jun 30, 2014 at 2:26 PM, Benjamin Tissoires
wrote:
> Wacom tablets can share different physical sensors on one physical device.
> These are called siblings in the code. The current way of implementation
> relies on the USB topology to be able to share data amongs those sensors.
>
> We can
On Mon, Jun 30, 2014 at 2:26 PM, Benjamin Tissoires
wrote:
> Hi guys,
>
> this patch series is a cleanup for the Wacom USB driver.
>
> I started working on this topic when I saw patches floating around which
> implemented a report descriptor parser within the wacom.ko module.
> However, we already
44 matches
Mail list logo
