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?
>
> Hi Edward,
Just to get my terminology clear, because there are two types of Bluetooth
on this tablet we usually say paper-mode or BLE mode (Bluetooth Low Energy)
when we're talking about the paper communications and Bluetooth Classic
when we're talking about using the tablet wirelessly.
At least one of the reasons that we don't report the capacitive events is
that the kernel doesn't have an event code for these events [1].
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.
>
> The upstream patches do provide USB support for the Intuos Pro 2 through
the generic (HID) codepath, this is why you don't see the 0x357 and 0x358
PIDs. The generic code path is designed to give a degree of forward
compatibility by adding support for usages instead of adding support for
PIDs. The patches also provide Bluetooth Classic support through the
traditional codepath [2].
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.
>
> I'm going to defer to other open source contributors on questions about
the potential for and mechanics of potential BLE support.
Best,
Aaron
[1]
https://github.com/torvalds/linux/blob/master/include/uapi/linux/input-event-codes.h
[2] https://www.spinics.net/lists/linux-input/msg49208.html
> 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
