Bug 855294 - Add an option to set Tablet PC mode in Wacom plugin for gnome-control-center
Add an option to set Tablet PC mode in Wacom plugin for gnome-control-center
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: control-center (Show other bugs)
6.4
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Rui Matos
Desktop QE
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-07 05:11 EDT by Olivier Fourdan
Modified: 2017-12-06 05:25 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-12-06 05:25:32 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Bugzilla 683568 None None None 2012-09-07 08:08:17 EDT

  None (edit)
Description Olivier Fourdan 2012-09-07 05:11:19 EDT
Description of problem:

The wacom plugin in gnome-settings-daemon can set the "TPCButton" option for Wacom tablets, but this option is disabled by default in GConf and there is no UI option to enable the Tablet PC option.

Version-Release number of selected component (if applicable):

control-center-2.28.1-37.el6

How reproducible:

Always

Steps to Reproduce:

1. Using a Tablet PC device or a screen tablet such as a Cintiq, open the gnome-wacom-properties utility
2. Check for an UI option to enable or disable "Tablet PC" mode
  
Actual results:

No UI to enable/disable Tablet PC mode

Expected results:

The UI should allow enabling/disabling "Tablet PC" mode

Additional info:

gnome-settings-daemon already has the code to set "Tablet PC" mode for the device, what is missing is just the UI.

This feature needs to be implemented upstream first as it's not in GNOME 3.x either and the UI would need to be reviewed by the GNOME design team.

A workaround is to set the corresponding GConf key manually using gconf-editor or gconftool-2.

e.g.:

$ gconftool-2 --set "/desktop/gnome/peripherals/wacom/$(cat /var/lib/dbus/machine-id)-usb:056a:0027/tablet-pc-button" --type boolean true
Comment 2 Olivier Fourdan 2012-09-07 08:08:17 EDT
Opened bug on gnome.org 683568 to track that feature upstream.
Comment 3 Ping 2012-09-07 15:27:10 EDT
Although enabling "Tablet PC" button mode change in UI is the key subject of this request, I'd like to make sure we do not miss the important nature of its default mode for different devices.

By default, xf86-input-wacom enables "Tablet PC" button mode for all Tablet PCs while disabling the mode for all other tablets, including LCD tablets such as Cintiqs. However, users may configure the mode through xorg.conf.d or xsetwacom command (in a start up script) to change the mode before driver starts.

So, a proper way to display the mode in control-center is to retrieve its value from the driver. This can be done through supported X server/driver property or xsetwacom command.

In fact, all current modes/values displayed in control-center should be retrieved from the driver directly. Any guessed/assumed/hard-coded UI values will cause problems sooner or later.

Thank you Olivier for filing this request.
Comment 4 Olivier Fourdan 2012-09-10 07:18:15 EDT
Actually, it's not hardcoded values per se, it's default initial values in the schema.

As you know, GNOME uses GConf (now GSettings in GNOME 3 but the logic remains the same) to store its settings and both GConf and GSettings provide schemas which specify a default value when no value is set by the user.

When a user first login in GNOME, most settings are unset so the default from the schema will apply.

The Wacom plugin in gnome-settings-daemon is no exception, without any value set, the schema default will apply, and the default is FALSE in the case of "table pc button".

Also, please note that Jakub asked for the use case for the "table pc" mode where the buttons on the stylus only trigger when the tip is touching the surface, in bug 855200 comment 8

  https://bugzilla.redhat.com/show_bug.cgi?id=855200#c8

(It's probably more relevant in this bug than in bug 855200)
Comment 5 Ping 2012-09-11 14:16:08 EDT
Reply to Jakub for "Tablet PC" mode (aka TPC Button) use case.

TPC Button is a default feature/option used by Windows Tablet PC edition users. Since Tablet PCs that run RHEL normally have dual Windows and Linux installed, users prefer a consistent button behavior when they switch between OSes. Plus, most Tablet PC users have used Windows Tablet PC edition before they try Linux. That's why we agreed to enable TPC Button on Tablet PCs in xf86-input-wacom. But, it is disabled for all other Wacom devices by default.

So, the use case for TPC button would be:

1. For Wacom devices integrated in Tablet PCs, TPC Button is enabled by default;

2. For all other Wacom devices, TPC Button is disabled by default;

3. TPC Button option can be disabled or enabled through an UI for all Wacom devices.
Comment 6 Ping 2012-09-11 15:22:49 EDT
re #4: I understand the necessity of "default initial values" for UI. In fact, the default values are used in the old Wacom Control Panel (wacomcpl) too. We had a button called "Default" in each panel for users to set everything in the panel back to default after they have changed configuration. To support this UI feature, we added a get default option to xsetwacom.

However, default values are only a best guess of the options that most users would use with the device. The root cause of this issue can not be fixed by setting the initial values right. A Tablet PC user could have disabled TPC Button in xorg.conf.d or by xsetwacom. That is, TPC button mode should be FALSE when the user first logs in to GNOME. This happens because driver starts before gnome-settings-daemon. 

If we rely on default initial values, we could make those inexperienced users happy. But we can not satisfy the experienced users who normally have sophisticated initial settings which can be different from the default ones. 

I think a dynamic UI should display the current settings retrieved directly from the driver. gnome-settings-daemon should retrieve all values from the driver, even at the time when it starts to make sure it is in sync with the current device settings.
Comment 7 Jakub Steiner 2012-09-14 11:52:02 EDT
Based on the outlined use case, it's not the form factor that implies the behavior (ie a tablet pc == a notebook with an embedded wacom tablet). This inconsistency of stylus button behavior is an undeniable problem for dualboot users.

I would, however, see exposing this specific case for everybody in the system settings as a UI failure and go for a key only. Figuring out the default may not be trivial, nor bulletproof, but I would aim for opting in to the behavior by looking at the form factor AND a windows partition. I see no reason for this to be optional for cintiq users or people who never used windows on a tablet pc.
Comment 8 Olivier Fourdan 2012-09-14 12:05:03 EDT
Note, we already have the GSettings/GConf key for TabletPC mode as indicated in comment #0.

While we may use libwacom's function libwacom_is_builtin() to determine (part of) the form-factor, I don't think looking for a Windows partition is suitable.

The default in the driver does not check for Windows partitions.

Even if a there is a FAT, FAT32 or NTFS partition on the system does not prove this is a Windows installation (most usb sticks are formatted with those filesystems these days for example) - That sounds out of place for a Wacom tablet option.
Comment 9 Jakub Steiner 2012-09-14 13:05:41 EDT
Well I short circuited to the first thing that came to my mind. grub would probably provide a better way to tell if it's a dualboot system. What I meant is that the form factor alone doesn't give enough guidance for a good default.
Comment 10 Ping 2012-09-15 14:36:00 EDT
re c#9: Jakub, you made a very good point. But I agree with Olivier.

control-center or settings-daemon can not and should not decide the default. Device settings/defaults are decided by the driver, which communicates to the device directly all the time. Please see my reply to c#7 for more explanation.
Comment 11 Ping 2012-09-15 14:47:51 EDT
(In reply to comment #7)
> Based on the outlined use case, it's not the form factor that implies the
> behavior (ie a tablet pc == a notebook with an embedded wacom tablet). This
> inconsistency of stylus button behavior is an undeniable problem for
> dualboot users.

By default, there would be no problem for dualboot users as long as we support TPC button by default on Linux. Since by default, Windows TPC users get TPC button mode enabled in Windows TPC edition. This is purely talking about the default case.

However, Windows TPC users can change TPC button mode. Users can turn the mode off in Windows control panel if they do not like it by some reason. From that moment on, their tablet will have the TPC mode diabled even if they reboot the system. The new value becomes their initial value now.

> I would, however, see exposing this specific case for everybody in the
> system settings as a UI failure and go for a key only. Figuring out the
> default may not be trivial, nor bulletproof, but I would aim for opting in
> to the behavior by looking at the form factor AND a windows partition.

Then, what value should control-center use for the case I mentioned above: user turned TPC button mode off? Even there is a windows partition, it does not mean TPC button is always enabled. That's why this "guess" "can not satisfy the experienced users who normally have sophisticated initial settings which can be different from the default ones".

> I see no reason for this to be optional for cintiq users or people who
> never used windows on a tablet pc.

There is another use case I forgot to mention:

When TPC Button mode is enabled and tip presses on the tablet: left button event is ignored if there are other buttons pressed the same time;

When TPC Button mode is disenabled and tip presses on the tablet: left button event is sent even there are other buttons pressed the same time;

For example, some Cintiq or Intuos users may want to turn TPC Button on since their application may translate left click + button 5 as different features from button 5 only feature. They would like to draw (tip is pressed) while they can use button 5 only feature.

As for people who have never used windows on a tablet pc, we are offering them a feature/option. They may become experienced users at some point. Making the option unavailable to them is defeaturing the driver/UI.  

All in all, I think retrieving the value from driver directly is the way to go. Why do we want to guess when the actual value is already accessible?
Comment 12 Olivier Fourdan 2012-10-12 04:30:18 EDT
(In reply to comment #11)
> [...] 
> All in all, I think retrieving the value from driver directly is the way to
> go. Why do we want to guess when the actual value is already accessible?

Which raise another question, why would we want to set that value in gnome-settings-daemon?

Retrieving the value from the driver to configure the driver the same is useless, better leave it untouched and the driver settings will remain as-is.

I can't find a way with gsettings to tell if value is explicitly set or is taken from the schema (if you know how to achieve this, please let me know), so that would require another setting to decide whether or not the setting "tablet-pc-button" is to be applied.
Comment 13 Ping 2012-10-12 19:24:41 EDT
(In reply to comment #12)
> Retrieving the value from the driver to configure the driver the same is
> useless, better leave it untouched and the driver settings will remain as-is.

Retrieving values from driver is not for configuring them. It is for displaying the current settings in g-c-c. We need to display current settings before users can change them in g-c-c.

> I can't find a way with gsettings to tell if value is explicitly set or is
> taken from the schema (if you know how to achieve this, please let me know),
> so that would require another setting to decide whether or not the setting
> "tablet-pc-button" is to be applied.

I do not know how g-s-d works. I can not make a suggestion. Maybe Peter, as a driver developer, knows what I mean?

Peter, you know both g-s-d and xf86-input-wacom. Can you figure out where is the misunderstanding between Olivier and me?
Comment 14 Peter Hutterer 2012-10-15 02:42:36 EDT
(In reply to comment #12)
> I can't find a way with gsettings to tell if value is explicitly set or is
> taken from the schema (if you know how to achieve this, please let me know),
> so that would require another setting to decide whether or not the setting
> "tablet-pc-button" is to be applied.

instead of a boolean, use an enum that includes a "state not yet set by user" value.

(In reply to comment #13)
> Peter, you know both g-s-d and xf86-input-wacom. Can you figure out where is
> the misunderstanding between Olivier and me?

I don't think there is one. AFAIU, Olivier is wondering about how to implement the three states of "enabled", "disabled" and "neither, take driver default".
Comment 15 Olivier Fourdan 2012-10-15 03:21:07 EDT
(In reply to comment #13)
> > Retrieving the value from the driver to configure the driver the same is
> > useless, better leave it untouched and the driver settings will remain as-is.
> 
> Retrieving values from driver is not for configuring them. It is for
> displaying the current settings in g-c-c. We need to display current
> settings before users can change them in g-c-c.

Not necessarily. What I have in mind is a 3 state option for the TPCButton settings, [Driver] [On] [Off], with "[Driver]" being whatever the driver initial state is (no need to tell if it's [On] or [Off], g-c-c would just leave it untouched).

> > I can't find a way with gsettings to tell if value is explicitly set or is
> > taken from the schema (if you know how to achieve this, please let me know),
> > so that would require another setting to decide whether or not the setting
> > "tablet-pc-button" is to be applied.
> 
> I do not know how g-s-d works. I can not make a suggestion. Maybe Peter, as
> a driver developer, knows what I mean?

Well, it's mostly meant for GNOME devs, was not intended as a direct question to you Ping, sorry for not being clear.
 
> Peter, you know both g-s-d and xf86-input-wacom. Can you figure out where is
> the misunderstanding between Olivier and me?

I am just trying to figure how to implement what you're requesting is a simple way, without possibly break too far from existing settings.
Comment 19 James Pearson 2013-06-01 15:21:45 EDT
We've just moved users to 6.4 - and some have complained that there is no longer a "Side Switch Mode" ("TPCButton") option in the Wacom prefs tool that used to exist in the old wacomcpl tool (which has now been deprecated) - so I guess the lack of this option is a regression from 6.3 ?

We don't have screen tablets - just Intuos tablets, but we have users that prefer this 'Tablet PC' mode of operation
Comment 20 RHEL Product and Program Management 2013-10-14 00:48:02 EDT
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 21 Jan Kurik 2017-12-06 05:25:32 EST
Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.

The official life cycle policy can be reviewed here:

http://redhat.com/rhel/lifecycle

This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:

https://access.redhat.com/

Note You need to log in before you can comment on or make changes to this bug.