Thanks for your detailed explanations. I ran those commands and could
confirm that the codes are as you explained.
I was hoping the problems could arise from wrong configuration files and
not from GNOME control panel instead. I was not expecting so many low
level differences between Wacom models either.
Regards,
Alicia.
On 01/03/2018 12:21 AM, Jason Gerecke wrote:
> Hi Alicia,
>
> I'll try to answer each question of yours in turn:
>
> On Wed, Dec 27, 2017 at 1:20 PM, Alicia Boya <ntr...@gmail.com> wrote:
>> Hi.
>>
>> I'm a bit sad that my Wacom tablet (CTH-670) is so poorly supported in
>> gnome. The Wacom control panel does not recognize the stylus ("No stylus
>> found", even when holding it on top of the tablet), two out of four express
>> keys are incorrectly mapped as each other in the GUI and one is not even
>> detected there.
>>
>> I can get everything working using xsetwacom in the terminal though. Is
>> there any way I can improve this? I looked at /usr/share/libwacom but there
>> are many things that I don't understand:
>>
> The Wacom panel within the GNOME Control Center has a few known issues
> with Bamboo/Intuos devices. Most of these issues stem from differences
> in how those devices appear to the system, compared to their
> higher-end Cintiq/Intuos Pro cousins. Since most issues are with the
> control panel rather than the drivers, you'll probably want to check
> out https://bugzilla.gnome.org/
>
>> For instance, where do the hexadecimal codes for the styli come from? How do
>> I get one for my stylus? Are they arbitrary and I can't choose whatever
>> integer or do they need to match a code coming from the hardware? How would
>> I retrieve that code for my stylus?
>>
> Those particular hex codes are transmitted by some styli to the tablet
> so that drivers and software can differentiate different types of
> pens. Most tablets that only support a single kind of stylus (like the
> CTH-670) don't report a hex code.
>
> If a hex code is reported, the value for a particular type of pen can
> be discovered either by examining the kernel event stream or the X11
> device properties:
>
> Kernel:
> Run `sudo evemu-record | awk '/ABS_MISC/'` and select the pen device.
> Bring the pen in and out of prox to see if any ABS_MISC events are
> sent. The [decimal] number at the end of each line is this code.
>
> X11:
> Bring the pen in and out of prox, and then run `xinput list-props <id>
> | grep "Wacom Serial IDs"` for the pen device. The third list item is
> a [decimal] number corresponding to the code. Very small values (15 or
> less) are "fake" IDs that the X driver creates for devices which don't
> actually report a value. The value "2" in particular is used to mean
> an unknown generic pen.
>
>> Unlike some other .tablet files, bamboo-16fg-m-pt.tablet (the one for
>> CTH-670) does not have a Styli property. May this be the cause the stylus is
>> not recognized in gnome wacom settings?
>>
> The CTH-670 shouldn't report any stylus IDs (the "kernel" test above
> shouldn't produce any output, and the "X11" test above should have "2"
> for the third list item) so there shouldn't be a "Styli" line within
> the tablet file. Its possible that the GNOME expects a styli line to
> exist, but that would be a bug. Its also possible that some other bug
> in GNOME is preventing the control panel from detecting the pen.
>
>> Also the express keys: what is the relation between the button letters used
>> in the `.tablet` files (A, B, C, etc.) and the numeric button numbers used
>> in xsetwacom?
>>
>> I have noticed that in the case of my tablet buttons don't use sequential
>> codes:
>>
>> (extract from my set-up-wacom.sh script)
>> # pad buttons from top to bottom, with the hardware button number they emit
>> PAD_1=1
>> PAD_2=9
>> PAD_3=8
>> PAD_4=3
>>
> This is kinda difficult to explain, but I'll do my best:
>
> libwacom uses letters (e.g. "A", "B", "C", "D", "E", etc.) to
> represent physical buttons. A "layout" SVG defines where each of those
> physical buttons exists on the tablet.
>
> When a particular button is pressed, the kernel can send either
> semantic button events (BTN_LEFT, BTN_RIGHT, BTN_FORWARD, BTN_BACK) or
> generic button events (BTN_0, BTN_1, BTN_2, BTN_3, BTN_4, etc.)
> depending on the tablet. Generally speaking, consumer tablets like the
> CTH-670 send semantic events, while professional tablets send generic
> events.
>
> In response to a button event from the kernel, the X driver has to
> translate it into a corresponding X button. X11 uses numbered button
> events that have taken on semantic meaning over the years: 1 (left
> click), 2 (middle click), 3 (right click), 4 (scroll up), 5 (scroll
> down), 6 (scroll left), 7 (scroll right), 8 (navigate back), 9
> (navigate forward), 10 (undefined), 11 (undefined), etc. For historic
> reasons, our driver does not translate any button to buttons 4-7.
>
> For your particular device, the libwacom layout file says that the
> buttons A-D are arranged vertically from top to bottom. These buttons
> send (BTN_LEFT, BTN_FORWARD, BTN_BACK, BTN_LEFT) from the kernel. The
> X11 driver translates these to buttons 1, 9, 8, 3.
>
> The GNOME Control Center doesn't (yet) properly support devices which
> use semantic events, however. It assumes that tablets always send
> generic buttons. Since your tablet has four buttons, this means that
> it expects our driver to send X11 buttons 1, 2, 3, and 8. This is the
> reason that buttons seem to be in the wrong location and why one of
> the buttons isn't recognized by the control panel at all.
>
> Press top button ("A") -> X11 button 1 sent -> GNOME thinks button "A"
> Press next button ("B") -> X11 button 9 sent -> GNOME thinks no button
> Press next button ("C") -> X11 button 8 sent -> GNOME thinks button "D"
> Press bottom button ("D") -> X11 button 3 sent -> GNOME thinks button "C"
>
> The very latest release of libwacom added an "EvdevCodes" setting to
> the tablet files which explicitly states what kernel event each button
> letter will send. GNOME doesn't use this information yet, but it
> *could* use it to determine exactly which X11 button event to expect.
> Once GNOME starts using this information, it should result in the
> control panel recognizing all of the buttons in the right place.
>
> BTW: I have a script at [1] which you can use to change the button
> mappings of your tablet (either temporarily through xsetwacom, or
> semi-permanently through xorg.conf.d) so that GNOME sees the buttons
> it expects. Its helpful to work around this issue if you prefer to use
> the GUI instead of xsetwacom all the time :)
>
>
> [1]: https://gist.github.com/jigpu/fde784840ba5731726e7382952b0d5ed
>
> 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....
>
>> Regards.
>> --
>> Alicia.
>>
------------------------------------------------------------------------------
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
