I totally missed the patch covering USB stuff; I see now that all features
appear to be handled via the HID pipeline, including touch. What's the
recommended procedure for building those patches? I'm used to the
github/pull request process. Do I need to check out the kernel source at
some specific commit, and then manually apply the 8+ patches and build the
whole kernel + modules, or is there a shorter route that you use? (sorry
for newbie questions)
On Mon, Jan 30, 2017 at 3:16 PM, Edward Kaszubski <ekaszub...@gmail.com>
wrote:
> 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
