Launchpad Entry: wacom-tablets-ui
Contributors: Alberto Milone
Packages affected: wacom-tools
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.
Ubuntu now provides a simple graphical interface to enable and calibrate computer drawing tablets.
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.
- 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
- -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
- xsetwacom will still be able to set properties on the fly, whatever method end up being used to set up tablets
- 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.
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.
- 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
- Mode (Screen, Window → Relative/Absolute)
- Pressure Sensitivity
- Click Threshold (or Button Threshold)
- 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 (different alternatives): we must distinguish the tablet configuration that is mandatory in xorg.conf in order to use the tablet, and preference settings :
- Enabling/Disabling the tablet:
- if we chose the wizard option (UDS December 2008 mockup) then users have to run the wizard whenever they want to disable or enable the tablet in xorg.conf. If the wizards disable the tablet by removing the lines in xorg.conf, then the wizard will pop up at each boot, even when the user has chosen to disable the tablet for any good reason (since they can still keep it plugged or, for TabletPC, they don't have a choice and it's always plugged, even if for a while the user uses his TabletPC as a normal laptop). if the wizard comments line instead, when will it know when the user want to enable a model of tablet again after a period of not using it?
- if we chose a selection button in the GUI, users can enable and disable a model of tablet at will. Preferences for the model of tablet are greyed out as long as the button is not ticked. When the user tick the button, he is immediately asked for the administrative password, and told to restart X for the change to take effect.
- preferences settings :
- 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
- settings are applied immediately (so the user can test the results) and are saved when the user closes the window.
- Enabling/Disabling the tablet:
- either :
- makes the wizard show up when no relevant device is found in the xorg.conf
- pops up a window asking the user if he wants to configure his tablet devices, along with a "Do not ask me this question again" choice, then open the configuration tool.
- allows users to change the tablet model :
- maybe with a button to run the wizard again
- instead, maybe pop up a windows each time a new model of tablet is detected and that tablet has no lines in xorg.conf, then open the configuration tool with the model of tablet already chosen in the selection list.
- 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, or each time a change is made in xorg.conf, for example when disabling a model of tablet in xorg.conf)
- either :
- 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.
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.
- 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) if the user asks for it (TabletPC, Cintiq users and graphic designers will not want that)
- 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
UDS December 2008
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):
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.