On Mon, Jan 30, 2017 at 4:47 PM, Edward Kaszubski <ekaszub...@gmail.com>
wrote:
> 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)
>
If your kernel is 4.5 or newer you could check out the branch for-4.11[1]
and build input-wacom [2] from that branch instead of master. Support for
earlier kernels is currently in development and will be in the next release
of input-wacom.
[1]
https://sourceforge.net/p/linuxwacom/input-wacom/ci/jiri/for-4.11/~/tree/
[2] http://linuxwacom.sourceforge.net/wiki/index.php/Input-wacom
>
> 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
