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

Assumptions

Design

Loïc: I'm not sure there's any need for a wizard. A windows that pops up when the user first plugs in a tablet and no configuration is detected in xorg.conf for this model, asks the user if he wants to configure his tablet, then launch the configuration tool seems more than enough. Wizards don't seem like the Linux way, whatever the DE - last time I had to use one was on Windows, and it's always a pain. Aside from the integration concerns in a modern desktop, there's also the fact we don't want to force our users to restart the wizard each time they want to disable/enable wacom configuration in xorg.conf.

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

Test/Demo Plan

Mockups

UDS December 2008

Wizard:

wacom_wizard_800.png

Configuration Dialog

wacom_test1_comments_800.png

Other Mockup

(follow development at https://wiki.ubuntu.com/Wacom/PropertiesMockup and give feedback either there, on linuxwacom-discuss or on ubuntu-x mailing lists):

Mockup.png

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 accelerometer, 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.

Comments

FYI: I know about a small utility which does partially does wat this spec is talking about, see: http://www.alexmac.cc/tablet-apps/

Another wacom configuration tool is: http://www.gtk-apps.org/content/show.php/Wacom+Control+Panel?content=104309

CategorySpec

X/Blueprints/WacomTabletsUi (last edited 2009-05-18 10:23:11 by ip-81-11-185-100)