Hi Jason and Aaron,
Haha, it's actually been a great learning experience for me.
OK great! I looked over the linux-input patches and it looks like they only
cover bluetooth and the non-paper (idProduct 0x360, 0x361) tablets (have
you tried any of these tablets over USB?), whereas the work I've done
covers USB and the paper edition (0x357, 0x358) tablets. It looks like
there's a good amount of overlap between the bluetooth and USB reports in
terms of encoding, with a few exceptions, so those commonalities can just
be factored out and called on by both pipelines as needed. Side note: the
capacititive component of the ExpressKeys doesn't look like it's being
detected/handled; is that intentional?
Regarding paper mode, I'm definitely interested in continuing to work on
it. As mentioned earlier, I can already decode the "live mode" packets in
paper mode. I spent some more time looking through the source code for the
InkSpace app and was able to write some test code to decompress and decode
a simple drawing saved on the tablet's internal memory. I still don't fully
understand the compression technique being used, but everything appears to
work so I'll worry about that later :P
So yeah, like you mentioned, I think the biggest unknown is how to best
control/interface with the paper modes, since they're fairly different from
the other modes. We could use a sysfs entry as with the LEDs to enter/leave
live mode, and then post the live mode x/y/pressure data as pen data and/or
push it out via a character device so it could be written to disk. For
drawings saved on the tablet, we could create our own WacomFS filesystem
that would enter sync mode on mount, display basic info for existing
drawings, allow for deletion of drawings, and fetch + decompress the
drawings on copy. Similarly, it could be useful to provide a tool to
"replay" the movements in a saved drawing through a virtual tablet (but
that should probably happen at a higher level than the driver).
I'm refactoring my code a little now based on the conventions used in the
kernel patch; can you let me know whether that patch actually provides USB
support for the new tablets? If not, I'll post a link to my changes.
Also, can you please let me know what you think about sysfs for live mode
and WacomFS for sync mode? I'd be particularly interested in working on the
WacomFS idea if you think it's the right interface for sync mode.
Thanks!
- Edward
On Mon, Jan 30, 2017 at 8:52 AM, Jason Gerecke <killert...@gmail.com> wrote:
> Edward -- Wow! I wasn't expecting to see a new face tearing so deeply
> into these tablets yet!
>
> We've been working on this tablet too, and just sent a set of patches
> upstream to the kernel's "linux-input" mailinglist on Wednesday[1]. We
> were planning on starting the work to backport them into the
> input-wacom driver once they were accepted upstream. We hadn't put any
> thought into the Paper mode yet since it seemed to be so different
> from the regular USB/Bluetooth data modes that we're used to.
>
> I've CCed Aaron Skomra who wrote the upstream patches and who was
> planning on doing the input-wacom backport as well. It might be
> interesting to compare code.
>
> As for Paper mode, if you're interested in continuing to probe how it
> works, we'll try to help where we can. There hasn't been much activity
> on the mailinglist about the Bamboo Spark (which I believe Paper mode
> is emulating), but software to make it work still might be interesting
> to some people :)
>
> [1]: https://www.spinics.net/lists/linux-input/msg49184.html
>
> 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, Jan 29, 2017 at 6:16 PM, Edward Kaszubski <ekaszub...@gmail.com>
> wrote:
> > I did some more USB capture and was able to decode the Live mode packets;
> > they contain only x/y/pressure data. bytes 0-1 contain some ID info
> (they're
> > always 02 00), byte 2 is normally 0xa1, but appears to change to 0xa2 to
> > indicate the start of a stroke. byte 3 is the size of the message area in
> > bytes, and bytes 4-end contain up to 3 6-byte messages. The messages
> encode
> > ushort values for x, y, and pressure, and are in the form [ x_low |
> x_high |
> > y_low | y_high | p_low | p_high ]. A ff:ff:ff:ff:ff:ff message is sent to
> > indicate stroke stop.
> >
> > I started looking into Sync mode and the structure of the data being
> > transmitted, but the actual drawing content appears to be
> compressed/encoded
> > in some way. So I decided to dig into the InkSpace binary and realized
> it's
> > all written in JavaScript, and the communication layer appears to be
> totally
> > unobfuscated. So we basically have all the info we need to do anything
> with
> > these new tablets laid out for us in plain text. The relevant code (from
> > v1.0.29) can be found here:
> > https://drive.google.com/file/d/0B8PMEPBxi1PpNzVMbFotTWJnaTA .
> >
> >
> > On Sat, Jan 28, 2017 at 2:14 PM, Edward Kaszubski <ekaszub...@gmail.com>
> > wrote:
> >>
> >> Hi all,
> >>
> >> My girlfriend recently purchased the PTH-660P (Intuos Pro Paper Edition,
> >> Medium variant) and nothing worked out-of-the-box in linux.
> >>
> >> I went ahead and captured some USB data using wireshark in Windows for
> >> most of the tasks I could think of; let me know if you want any of the
> >> capture files:
> >> - First plug-in/probe
> >> - Pro Pen 2 tip/eraser/buttons
> >> - ExpressKeys (they have both capacititive and click data)
> >> - TouchRing
> >> - TouchRing LED toggle via center button
> >> - Multitouch (up to 10 fingers tested, and HID data says only 10 are
> >> supported)
> >> - Touch enable/disable switch
> >> - Paper mode (no pen/cursor data is transmitted in this mode; the tablet
> >> just records what you draw)
> >> - Sync paper-mode drawings with InkSpace app (the InkSpace app appears
> to
> >> ping the tablet every few seconds; if a new drawing is available, the
> tablet
> >> sends it over endpoint 0x82)
> >> - Live mode (tablet streams paper-mode data to InkSpace app; what you
> draw
> >> on paper shows up on-screen, but only in InkSpace app; sent over
> endpoint
> >> 0x82 just like paper sync)
> >>
> >> Based on the above, I was able to tweak linux-wacom to add support for:
> >> - Pen
> >> - Touchpad
> >> - Touch ring
> >> - ExpressKeys (both capacititive and click)
> >>
> >> Before I submit a patch and/or work on extra features, I just wanted to
> >> ensure I'm following the relevant guidelines and standards.
> >>
> >> These new Intuos Pro tablets are PTH-660/860 (medium, large) and
> >> PTH-660P/860P (medium and large paper edition), whereas the last
> generation
> >> are PTH-451/651/851 (small, medium, large). They have some quirks that
> do
> >> not appear to be handled by any of the current device types, and the
> paper
> >> editions have extra features that need to be handled separately.
> >>
> >> In terms of naming, I added new INTUOSP2<M/L>[P] (e.g. INTUOSP2MP) enum
> >> entries and wacom_status_ip2_irq, wacom_ip2_touch, wacom_ip2_touch_msg
> >> functions (where ip2 = intuos pro 2). I also added WACOM_PKGLEN_IP2,
> >> WACOM_BYTES_PER_IP2_PACKET, WACOM_REPORT_IP2_USB,
> WACOM_REPORT_IP2_TOUCH,
> >> WACOM_HID_DG_CONTACTMAX.
> >>
> >> The PTH-660P sends touch events over endpoint 0x85, and
> >> pen/touchring/buttons/status over 0x81. So similar to BAMBOO_PAD, I'm
> >> setting the type to something specific, then in
> wacom_parse_and_register, I
> >> use pktlen to differentiate between the two endpoints, and override the
> type
> >> of endpoint 0x81 to be HID_GENERIC. Also similar to BAMBOO_PAD, I added
> a
> >> quirk to set device_type to WACOM_DEVICETYPE_TOUCH.
> >>
> >> The HID_GENERIC type picks up the pen, ring, and non-capacititive
> buttons
> >> (the cap buttons have usage 0x950 instead of 0x940, so I added an extra
> case
> >> for that and they work)
> >>
> >> The HID entry for CONTACTMAX is 0xFF000055 instead of 0x000D0055 so I
> >> added an extra case to detect it.
> >>
> >> The touch packets are similar to the bpt3 packets, but they encode up
> to 5
> >> 8-byte messages in a fixed-length 44-byte packet instead of 7 8-byte
> >> messages. Additionally, when there are more than five touches, two
> packets
> >> are sent, with the second packet encoding touches 6-10. Due to this
> >> difference, I created functions wacom_ip2_touch and wacom_ip2_touch_msg
> >> based on the bpt3 versions but specific to ip2.
> >>
> >> Do these changes sound reasonable at a high level? Please let me know
> so I
> >> can submit a cleaner patch. Thanks!
> >>
> >> - Edward
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
