After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 675870 - Implement tablet area cropping/aspect ratio
Implement tablet area cropping/aspect ratio
Status: RESOLVED FIXED
Product: gnome-settings-daemon
Classification: Core
Component: wacom
3.4.x
Other Linux
: Normal enhancement
: ---
Assigned To: gnome-settings-daemon-maint
gnome-settings-daemon-maint
Depends on:
Blocks: 668907
 
 
Reported: 2012-05-11 12:25 UTC by Olivier Fourdan
Modified: 2012-06-11 14:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed patch (6.09 KB, patch)
2012-05-11 12:33 UTC, Olivier Fourdan
none Details | Review
Updated patch (6.09 KB, patch)
2012-05-11 12:35 UTC, Olivier Fourdan
reviewed Details | Review

Description Olivier Fourdan 2012-05-11 12:25:12 UTC
This bug is to implement the g-s-d part for the cropping of tablet area to match output aspect ratio (bug 668907)
Comment 1 Olivier Fourdan 2012-05-11 12:33:06 UTC
Created attachment 213863 [details] [review]
Proposed patch

This patch add the keep-aspect option to gnome-settings-daemon.

When set, it computes the device area to match the assigned monitor aspect ratio.

Such an option is incompatible with screen tablets (where it makes no sense), so changing the area to match the output aspect ratio does not interfere with calibration (which is not available for non-screen tablets).
Comment 2 Olivier Fourdan 2012-05-11 12:35:51 UTC
Created attachment 213864 [details] [review]
Updated patch

Fixed typo in original patch ("!!gsd_wacom_device_is_screen_tablet (device)")
Comment 3 Olivier Fourdan 2012-05-14 09:44:39 UTC
Thinking of it, it would be much better to use the actual monitor size (if available) instead of resolution, as pixels may not be square (or the resolution could be changed by the user).
Comment 4 Olivier Fourdan 2012-05-14 13:46:57 UTC
(In reply to comment #3)
> Thinking of it, it would be much better to use the actual monitor size (if
> available) instead of resolution, as pixels may not be square (or the
> resolution could be changed by the user).

Tried that, but that does not work reliably, the monitor is not reporting accurate sizes, so better stick with resolution.
Comment 5 Bastien Nocera 2012-05-17 17:51:18 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Thinking of it, it would be much better to use the actual monitor size (if
> > available) instead of resolution, as pixels may not be square (or the
> > resolution could be changed by the user).
> 
> Tried that, but that does not work reliably, the monitor is not reporting
> accurate sizes, so better stick with resolution.

It's good enough in Totem for us to guess the pixel aspect ratio. What problems did you get into?
Comment 6 Bastien Nocera 2012-05-17 17:53:05 UTC
Review of attachment 213864 [details] [review]:

Looks good.
Comment 7 Olivier Fourdan 2012-05-21 12:03:17 UTC
(In reply to comment #5)
> It's good enough in Totem for us to guess the pixel aspect ratio. What problems
> did you get into?

The reported size is not reliable, for example it reported a 23 meters high panel on my laptop (23000mm)...

   https://bugs.freedesktop.org/show_bug.cgi?id=49911

X devs (ajax and airlied) confirmed that physical display size can't be relied upon.
Comment 8 Olivier Fourdan 2012-06-11 14:40:23 UTC
committed