Ubuntu Wiki

• Launchpad Entry: wacom-tablets-ui

• Created: 2008-11-21

• Contributors: Alberto Milone

• Packages affected: wacom-tools

Summary

Currently there's no easy way for users to enable, configure and calibrate Wacom Tablets and Tablet PCs as they have to do it manually in the xorg.conf. For this reason we should develop a simple graphical interface which can write user settings to the xorg.conf and which allows testing of the stylus, eraser and buttons inside a drawable area.

Release Note

Ubuntu now provides a simple graphical interface to enable and calibrate computer drawing tablets.

Rationale

Tablets have never been simple to configure with Ubuntu. In the distant past, Ubuntu used to ship a hardcoded wacom config in xorg.conf, however this caused various other quirky problems on systems without tablets, and only addressed a subset of available tablet models, and thus was eventually dropped. With input-hotplug, these types of hardcoded configurations were considered the wrong way to do it anyway.

However, input-hotplug has not adequately covered this class of hardware so far, and users now must manually configure xorg.conf settings for all tablet devices. We are hopeful that in time this will change, but in the meantime we would like to have a GUI tool to enable users to perform these manual configuration steps more easily.

Use Cases

• Claire plugs in her USB tablet but HAL detects only the stylus
• Mark wants to configure the sensitivity of his tablet
• John wants to use the touch capability of his tablet PC
• Gwen wants to constrain the movement of her stylus to her first screen

Assumptions

• -evdev will not gain adequate multi-device support in time for Jaunty
• wacom-tools will not gain adequate input-hotplug support in time for Jaunty

Design

• Configuration wizard:

  • hardware profiles for different models
  • custom profile:
    • users are asked a few questions on the characteristics of their tablet/tablet PC
    • buttons on the tablet, touchscreen, (serial or USB) connection, etc.

• Configuration dialog:

  • the different components (stylus, eraser, pad, touch) can be configured separately
  • some components are not available in certain hardware configurations
  • some options are not available in certain components
  • options:
    • Mode (Screen, Window → Relative/Absolute)
    • Pressure Sensitivity
    • Click Threshold (or Button Threshold)
    • Speed
    • Allow cursor to move across multiple screens (for screens with different resolutions)
    • Rotation is done using the existing Screen Resolution tool and not handed here
      • (Future work may leverage the upcoming python RandR bindings to do this in-tool)
  • a drawing area to test the pressure sensitivity of stylus and eraser devices
  • applies/saves settings (2 alternatives):
    • settings are applied and saved only after clicking on the “Apply” button
    • settings are applied immediately but are saved only after clicking on the “Save” button
  • actions:
    • makes the wizard show up when no relevant device is found in the xorg.conf
    • allows users to change the tablet model (maybe with a button to run the wizard again)
    • displays a dialog to warn the user that s/he has to restart X with the tablet plugged in in order to use it (when the tablet is already configured in the xorg.conf)

• UI:

  • The first supported frontend will rely upon GTK.

  • A drawing area (using Cairo and GooCanvas for the GTK UI) for testing

We anticipate that upstream will eventually support input-hotplug on tablets, or that better workarounds will become available than modifying xorg.conf (e.g. adjusting settings through dbus). Since this change could have major architectural impacts on this tool, we should keep the design simple and the number of supported features constrained, as it will be likely that we will need to drop or change significant portions of this tool at that time. The fewer features we provide, the easier the transition will be to the new architecture.

Implementation

• Tablet profiles:

  • hardware profiles for different models (OpenSuse's Sax2 already does this)

  • custom profiles for unsupported models

• Tablet tools settings (stylus, etc.):

  • applied immediately with xsetwacom (without having to restart X)

  • settings to turn on the device are saved to the xorg.conf through X-Kit and PolicyKit

  • settings to configure the device are saved to an rc file, to be parsed by a runtime wacom setup tool
  • User is prompted to reboot for the settings to take effect, and told to reboot with the device attached.

• Wacom options:

  • depend on the hardware profile and are set according to what the wacom man page suggests

  • Allow cursor to move across multiple screens (for screens with different resolutions)

    • easy to do with RandR 1.2

    • Xinerama. Parse the ServerLayout section with X-Kit (ServerFlags too)

    • Mode has to be set to Relative otherwise the stylus won't be able to move across 2 or more screens

Test/Demo Plan

• Requirements for deployment to universe:
  • Tool must build with no errors and minimal warnings on a stock Jaunty system
  • Installation must pull in correct dependencies and run without error on a stock Jaunty system
  • Verify able to write settings to xorg.conf and other config files correctly when used multiple times in succession.
  • Verify able to (independently) configure 2 different models of tablets
• Requirements for inclusion in main:
  • Verify able to (independently) configure 5 different models of tablets, including 2 non-Wacom tablets
  • Verify able to (simultaneously) configure 2 tablets on one system, such that both devices work and that each device's settings can be further customized correctly
  • Verify able to set up tablet A, remove it, set up tablet B with different settings, remove it, reattach tablet A, and have it come up with the correct settings for tablet A.
  • Verify that after making configuration changes at run time, that the same changes are present after reboot
  • Verify ability to configure a tablet that does not have settings listed in the database
  • All strings must be translatable
  • All help buttons must display a help page, or link to online documentation in wiki
  • Must be accessible from the Applications menu

Mockups

UDS December 2008

Wizard:

Configuration Dialog

Unresolved issues

None

BoF agenda and discussion

Gobby session - UDS

== Status quo ==
 * Have to find the wiki page for configuration (https://help.ubuntu.com/community/Wacom)
 * Hard to set up since you have to configure in xorg.conf.  Need specific info for your hardware.
 * When plugging in a USB tablet, HAL will detect it, but only sets up the pen.  But you need the tablet, eraser, etc. to also be detected.
 * It's not uncommon to trigger other X bugs when fiddling with xorg.conf settings.

Planning to add a new configuration UI.  Something like a configuration wizard, for selecting configuration profile.  But should also be able to create a new profile by answering a few questions.

Question - getting this working in upstream automatically?
- evdev doesn't support what wacom needs
- wacom doesn't support input-hotplug (they do support it through a workaround, which is more a hack)
So we're waiting on upstream work.

Configuration dialog
* the different components can be configured separately (stylus, eraser, pad, cursor, touch)
* Some components are not available in certain hardware configs
* Some options are not available in certain components
* Options:
 * Mode (screen, window -> relative/absolute)
 * Pressure Sensitivity
 * Click threshold (or button threshold)
 * speed
 * Allow cursor to move across multiple screens (for screens with different resolutions)
* A drawing area to test the presure sensitivity of stylus and erase devices
* Applies/saves settings (2 alternatives)
 * Saved only after clicking on "Apply" button
 * Applied instantly but only after clicking on the "Save" button
        Loïc : we can separate the activation of wacom devices (write default configuration in xorg.conf) and the properties settings, which can be applied on the fly with xsetwacom and saved after exiting the window in an user ~/.wacomrc file, that would contain a set of xsetwacom lines. That eliminates the need for both Save and Apply buttons, which would make our Gnome friends happy. See mockup at https://wiki.ubuntu.com/Wacom/PropertiesMockup 
 * User-configurable makes sense from a shared workstation where two users have their own pens.  Each can have their own ~/.wacomrc (~/.config/wacom.conf?)
 * Revert dialog?  (Intrusive?)  Timeout to revert if user doesn't click in time.
  * Better: auto-fallback on timeout, ask whether settings are okay

What about two screens?  One for drafting, one for quick doodling.

Actions:
  * Makes the wizard show up when no relevant device is found in the xorg.conf
  * Must allow users to change the tablet model (maybe with a button to run the wizard again)
  * Displays a dialog to warn the user that s/he has to restart X with the tablet plugged in order to use it (when the tablet is already configured in the xorg.conf)

Implementation:
  Tablet profiles:
   * hw profiles for different models (OpenSuse's Sax2 already does this)
   * custom profiles for unsupported models
   
  Tablet tools settings (stylus, etc.):
   * applied immediately with xsetwacom (without having to restart X)
   * saved to the xorg.conf through X-Kit and PolicyKit
   
  Wacom options:
   * depend on the hardware profile and are set according to what the wacom man page suggests
   * Allow cursor to move across multiple screens (for screens with different resolution)
     * easy to do with RandR 1.2
     * Xinerama, Parse the ServerLayout section with X-Kit (ServerFlags too)

Unresolved issues
  How to deal with screen rotations?
    * Use the new Python RandR API
    * provide a combobox to allow users to rotate the tablet manually
    * create a daemon which listens to rotation events and rotates the tablet automatically
    * some TabletPC users reports problems with rotation when waking up from suspend - the rotation isn't kept for the wacom device, while the screen is still rotated.
  


== Distinctions between touchscreens and tablets ==

Touchscreens and TabletPC's should be treated as different cases.  Probably using some other tool for configuration.  But perhaps some UI elements or underlying components could be shared or done similarly.
What is the reason for a different UI? TabletPC can also use stylus (and same options) and tools as wacom tablets, the configuration is similar (calibrated as a Cintiq)

For purposes of discussion, touchscreens can be defined as devices that use passive pointers (fingers, styli, etc.), and tablets as devices that use active pointers (pen, mouse, drafting tool, etc.)  As a result, there are significant differences in the set of adjustable configuration for each class of device.

Given this, while it makes sense to track the UI for both classes of device, and attempt to reduce duplication to ease documentation and consistency of user experience, it does not make sense to restrict the possibilities available for the tablet devices in order to allow direct support for both touchscreens and tablets in the same process directly.

== Handling Screen Rotation ==

Many screens allow rotation.  Some of these screens may have an integrated tablet, and some may not (where the user is using a separate tablet).

In order to support use cases like rotation of a monitor at a desktop workstation while not moving the separate desk-mounted tablet, and active rotation of a tablet PC with internal accellerometer, the configuration tool for the tablet ought to allow the user to select a rotation policy to match their most common uses.

With sensitivity testing, unless we can easily reuse an existing thing, we may leave this as a phase-2 functionality, as we have limited time for Jaunty.  It would be great to have, but the priority will be getting the basic application working nicely.  Users always have the option to test the settings out in an application and restart the config tool.

For testing sensitivity, there's already an area in one of the tools in Gnome - see Fig. 2 on https://wiki.ubuntu.com/Wacom/PropertiesMockup where I just copy-pasted from another application. That's a different information than a drawing area, since the drawing area never translates exactly in a program (each has their own settings also for sensitivity) while a box like the "Test" one in Fig. 2 allow to see how much strenght is needed to go to full.

CategorySpec