Thanks for the explanations :)
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.
OK, I'm on ubuntu 16.04/ linux 4.4 but I think I can jump up to 4.8.
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.
OK, I understand that the tablet is a dual-mode bluetooth device; are you
saying that the paper features (downloading files off the tablet and "live
mode") are handled via BLE, while the pen/touch/button data are handled via
BT Classic?
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].
In my changes, I just treated them as a second set of 8 buttons to allow
for additional inputs, but the fact that the a cap button is necessarily
pressed when pressing the corresponding click button can make it awkward,
so this makes sense.
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].
Understood, all the HID stuff makes way more sense now :)
I'm going to defer to other open source contributors on questions about the
> potential for and mechanics of potential BLE support.
I went ahead and implemented the core features of WacomFS (over USB) and it
works pretty well. I can currently:
- present a directory listing corresponding to the files saved on the
device (based on the number of files reported by the GetFilesCount cmd)
- set the size attribute for the "oldest" file (based on the size
(compressed) reported by the GetFileInfo cmd)
- download and decompress the oldest file on read, and pass the
decompressed buffer back to userland
- delete the oldest file off of the tablet on unlink (and query the tablet
for the size of the next file, if any, and update its perms + attributes)
- a remount is currently required to see new files, and the code assumes
you don't add any files between deletions
So the main issue is that it seems like the USB protocol can only perform
operations on the "oldest" drawing, which means that while I can create a
filesystem entry for each file, it only makes sense to set the size and
time attributes for the oldest file, and all files other than the oldest
file have no r/w/x perms (to make it clear that they cannot be modified).
cp, rm, mv, etc all work as expected (mv correctly triggers a download
followed by a delete, which is nice). However, the fact that the rest of
the files are effectively just placeholders to indicate the number of files
stored on the tablet makes things a little awkward, and I'm wondering if
anybody has any ideas for alternatives/improvements. Thanks!
The source for WacomFS is up on github [1] (I just branched off of
input-wacom:master and targeted kernel 3.17).
[1] https://github.com/ekaszubski/input-wacom/compare/
748c933163eaa61f2c01cea2dcd368f0875e8411...wacomfs
On Wed, Feb 1, 2017 at 9:19 AM, Aaron Armstrong Skomra <sko...@gmail.com>
wrote:
>
>
> 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
