All of lore.kernel.org
 help / color / mirror / Atom feed
From: redstrate <josh@redstrate.com>
To: "José Expósito" <jose.exposito89@gmail.com>
Cc: benjamin.tissoires@redhat.com, jikos@kernel.org,
	kurikaesu@users.noreply.github.com, linux-input@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] HID: uclogic: Add support for XP-PEN Artist 22R Pro
Date: Sun, 01 Jan 2023 10:40:59 -0500	[thread overview]
Message-ID: <5985890.lOV4Wx5bFT@adrastea> (raw)
In-Reply-To: <Y7Gn4wVx3CgGYSeA@fedora>

> 
> Ah cool, then I guess we can remove the cases for "4" and "8"? I'd be
> nice to stick with decimal numbers in all cases for consistency.
> 

Oh yeah we totally could, I'm not sure why the double cases were there in the 
first place - it might have been for another device included in the original 
patch.

> 
> Also, buf[6] does not indicate the number of buttons (20?).
> 
> Did you check with Wireshark if the Windows driver is doing something
> different for your tablet? It'd be nice to avoid adding quirks but it
> might not be possible :S
> 
> We can ignore buf[12] and buf[14]. buf[0] indicates the size of the
> descriptor (12), so the last two bytes are random memory.
> 

I don't even think I have to drop into Windows, we have a userspace linux 
program for XP-PEN but I haven't tested it with this tablet yet. Yeah, I'd 
also like to avoid implementing device-specific quirks - hopefully I'll be able 
to shrink the init code but I might not be able to get rid of all of it. It's 
really weird that almost everything else (data frame wise) is the same, with 
the exception of init. And yes, this tablet contains 20 buttons and nothing in 
that buffer indicates button count :-/



  reply	other threads:[~2023-01-01 15:41 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-26  3:11 [PATCH] HID: uclogic: Add support for XP-PEN Artist 22R Pro Joshua Goins
2022-12-26  8:29 ` kernel test robot
2022-12-26 10:31 ` kernel test robot
2022-12-26 11:22 ` kernel test robot
2022-12-29 19:06 ` José Expósito
2022-12-30 20:02   ` redstrate
2023-01-01 15:33     ` José Expósito
2023-01-01 15:40       ` redstrate [this message]
2023-01-02 19:49 ` [PATCH v2] " Joshua Goins
2023-01-02 22:46   ` kernel test robot
2023-01-03  1:58   ` kernel test robot
2023-01-03  8:27   ` Dan Carpenter
2023-01-05 17:38   ` José Expósito
2023-01-05 22:08     ` redstrate
2022-12-26 10:11 [PATCH] " kernel test robot
2022-12-29  9:29 ` Dan Carpenter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5985890.lOV4Wx5bFT@adrastea \
    --to=josh@redstrate.com \
    --cc=benjamin.tissoires@redhat.com \
    --cc=jikos@kernel.org \
    --cc=jose.exposito89@gmail.com \
    --cc=kurikaesu@users.noreply.github.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.