Re: [Linuxwacom-devel] RFC: Back to the tablet buttons representation (aimed at making an OSD window for the Expresskeys)
On Thu, Sep 27, 2012 at 11:32:48AM +0200, Olivier Fourdan wrote: > Hi all, > > We have been discussing the need for an OSD window for some time. > > For GNOME, I made a simple implementation (see bug 679062 [1]) which > seems to works quite well, but could be greatly improved with a more > accurate representation of the actual device. > > I believe the requirements would be: > > * Format should allow for rotation along with the tablet > orientation, and scale to match monitor's geometry > * Button should change aspect when pressed (so a static image is not > sufficient) > * Description should be generic enough so that it can be (re)used in > different apps/desktops if necessary > * Description should include at the very least the button name > matching the libwacom's buttonsX denomination, position, size and > label location > > Expectations: > > * Keep it simple for developers to implement the code, > * Keep it simple for artists to contribute new buttons/layouts when needed > > In the past we discussed the possibility to use the following > formats for that representation: > > * json (http://www.json.org/) >pro: fairly common and standard >cons: not necessarily natural for artists > * xkb_layout format >pro: already have a sample impl, in GNOME for keyboard layouts >cons: not exactly a standard and even less natural for artists > > Possible solution: > > * A set of buttons in SVG format - SVG in vector graphics so it can > be easily scaled/rotated and can be modified using CSS (see gtk+ > symbolic icon's routine) so it should be possible to create an image > of the same button being pressed. > * Tablet definitions include a description of the buttons present on > the device which includes: > > - Button name > - Button position > - Button size > - Label position > - Button image (is name of the corresponding SVG file) > > Advantage: > > * When different models of the same type of tablet use the same > buttons, no need to recreate the SVG images, > * The same SVG image of e.g. touchring button can be resused in a > popup small OSD showing current mode when changing mode. > * If someone does a purely symbolic representation fo the buttons, > the SVG images could be simply ignored: From the button name, an > apps can get the flags, deduce if it's a regular button, a > toushstrip or a touch ring, its size and thus draw accordingly > without even using the SVG image. > > Question: > > * Does any of the above makes sense? ;-) > * Is it simple enough? Or too simplistic? > * Is SVG appropriate for that? Do we actually need an accurate image > of the buttons? I think SVG should work well here. > * Assuming it makes sense, what unit should be used for the > position/size of elements? if you're talking about the tablet description, mm from the tablet origin in standard rotation, with the total size of the tablet provided as well. everything else is then scaling that needs to be done by the renderer. since we're describing a physical tablet, we don't really have any other options than mm. > * Should the representation be per tablet, or per side of tablet, ie > one description for the left buttons with their relative position, > same for right, top, etc? There are quite a few tablets, but I would worry about introducing features that are prone to errors. Let each tablet be describe as-is in one file without the need for includes or more complex merging and you're more likely to get clients to get it right. from a pure file-maintainance point of view, button sets that are consistent across a model series can be maintained as separate and merged into the final description file (the one clients would use) on install. having said that, my SVG and SVG renderer knowledge is limited, so all this may be easier than I thought anyway. Cheers, Peter > > I would really like to move forward with this, while at the same > time keeping things simple enough. > > [1] https://bugzilla.gnome.org/show_bug.cgi?id=679062 > > Cheers, > Olivier. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] RFC: Back to the tablet buttons representation (aimed at making an OSD window for the Expresskeys)
On Fri, Sep 28, 2012 at 01:25:39PM +0200, Olivier Fourdan wrote: > Hi Jason, > > Jason Gerecke said the following on 09/28/2012 12:19 AM: > >On Thu, Sep 27, 2012 at 2:32 AM, Olivier Fourdan wrote: > >>[...] > >> > >>Question: > >> > >>* Does any of the above makes sense? ;-) > >Seems logical enough. There's some hand-waving going on regarding the > >tablet definition language that needs to be sorted out though. > >Describing where and how large physical elements are sounds awfully > >like UI layout, so it may make sense to make use of languages that > >already exist for that purpose. > > > >>* Is it simple enough? Or too simplistic? > >For the moment, I don't see any problems. But don't underestimate the > >flexibility requirements. For example, the Cintiq 21UX2 has its touch > >strips located on the *back* of the tablet. You may run into problems > >describing the 3D position of elements with most 2D layout languages. > > Good point. But I have a bit of the same issue representing a 3D > layout on a 2D window... until Wacom starts making cubical or spherical tablets, we can assume the tablets are 2D plus a front/back bit. I don't think full 3D is something we need to worry about. Cheers, Peter > > >>* Is SVG appropriate for that? Do we actually need an accurate image of the > >>buttons? > >We probably don't need accurate button images and could get away with > >simplified representations created "directly" from the tablet > >definition. I wouldn't be against having something a little less > >symbolic though :) > > That's the point of having optional SVG images, usage would not be > mandatory. > > But then it's worth asking if SVG is worth it in this case. I guess > possibly not. > > >>* Assuming it makes sense, what unit should be used for the position/size of > >>elements? > >This kinda gets at the tablet definition language issues I was > >mentioning. Using a flat file with real-world units (e.g. centimeters) > >would be adequate to describe most anything, but would probably be > >hard to quickly write. Using an XML file could allow you to quickly > >describe things in relative terms, but would probably be more verbose > >when trying to get the layout "perfect". > >>* Should the representation be per tablet, or per side of tablet, ie one > >>description for the left buttons with their relative position, same for > >>right, top, etc? > >> > >I would probably represent the whole tablet. The symmetries are there, > >but I don't know if it'd be worth the programming work necessary to > >allow their description. It'd be more worth it to allow partial > >descriptions to be "included" into tablet definitions (e.g. describe > >the Intuos3 button layout once, and then include it twice in a > >half-dozen files), but I still don't know if it'd be enough. > > Well there are two problems really, one is the external interface, > ie what do apps get when querying libwacom for a layout, the other > one being how it's imimplemented within the libwacom database. > > For the former, a list of named buttons with their size and position > (and optional SVG representation) would be enough imho, whereas for > the later we can think of anything really, including XML and > > > external file inclusion. > > Cheers, > Olivier. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [PATCH 0/9] Multitouch support patches
On Sat, Sep 29, 2012 at 6:58 PM, Jason Gerecke wrote: > This set of patches adds multitouch support to the driver. The new > API made available in XI2.2 is used to report the location of all > contacts, allowing applications to work with the touch points themselves. > This is added as a new gesture mode, taking over whenever in-driver > gestures have been disabled and at least two fingers have come into > contact. > > The best way I've found to test this code at the moment is with a > gesture recognizer called "Touchegg". It should be in the repositories > for Ubuntu 11.10 (and will need compiling from source for 12.04), > has RPMs that can located through Google, and has a PKGBUILD available > for Arch in the AUR. > > This changes how data from the kernel is read into the channels for > tracking. It has the potential to introduce problems for tablets > that don't have touch, and I'd appreciate any Tested-By tags I can > get (especially on Protocol 4 [Bamboo] and Generic Protocol devices). > If my line-by-line review does come before much longer, feel free to take this and commit: Tested-by: Chris Bagwell I agree with direction your going with patches. Its in line with how I was planning on adding in if I got around to it. Chris -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [RFC PATCH 9/9]: Always allow single finger gestures
On Sat, Sep 29, 2012 at 6:58 PM, Jason Gerecke wrote:
> At the moment, disabling gestures disables *all* gestures. That includes
> the core "tap to click" gesture (and slightly-less-core "tap and hold to
> drag"). This patch changes the behavior of the driver to always allow
> single finger gestures, even if gestures have been disabled. This makes
> using the tablet a bit more user friendly when gestures have been disabled
> to allow multitouch to be handled outside of the driver.
> ---
> This patch has been marked RFC since I'm not sure if this is how we want
> the driver to act or not. Having touch enabled without "tap to click" is
> pretty useless IMHO, but I don't want to push this without getting an idea
> of possible ways it could backfire.
We shipped many a versions where touchscreen touch was enabled
regardless of Gesture enable. I was the one that changed it when I
centralized the touchscreen specific logic in wcmUsb and wcmISDV4 to
wcmTouchFilter so they wouldn't be fiting against each other.
I guess the change in behavior was I was being one part lazy and one
part not sure how XI2.2 was going to work and I thought there was
reasonable chance it would require us to stop sending all button
presses.
I think this patch is good idea and if issue arise we can add a
touchscreen specific touch disable property.
Acked-by: Chris Bagwell
>
> man/wacom.man| 6 +++---
> src/wcmTouchFilter.c | 17 +++--
> 2 files changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/man/wacom.man b/man/wacom.man
> index 4438cc5..c14a3d6 100644
> --- a/man/wacom.man
> +++ b/man/wacom.man
> @@ -232,9 +232,9 @@ The threshold applies to the normalised pressure range of
> [0..2048].
> The default is 27.
> .TP 4
> .B Option \fI"Gesture"\fP \fI"bool"\fP
> -Enable or disable in-driver gesture support on the device. Default: off
> unless the
> -tablet supports multi-touch. Note that disabling this option may allow the
> desktop
> -environment to detect gestures instead.
> +Enable or disable multi-finger in-driver gesture support on the device.
> Default: off
> +unless the tablet supports multi-touch. Note that disabling this option may
> allow
> +the desktop environment to detect multi-finger gestures instead.
> .TP 4
> .B Option \fI"ZoomDistance"\fP \fI"number"\fP
> If
> diff --git a/src/wcmTouchFilter.c b/src/wcmTouchFilter.c
> index b859973..49658ea 100644
> --- a/src/wcmTouchFilter.c
> +++ b/src/wcmTouchFilter.c
> @@ -250,6 +250,9 @@ static void wcmFingerTapToClick(WacomDevicePtr priv)
> WacomCommonPtr common = priv->common;
> WacomDeviceState ds[2] = {{0}}, dsLast[2] = {{0}};
>
> + if (!common->wcmGesture)
> + return;
> +
> getStateHistory(common, ds, ARRAY_SIZE(ds), 0);
> getStateHistory(common, dsLast, ARRAY_SIZE(dsLast), 1);
>
> @@ -379,7 +382,7 @@ void wcmGestureFilter(WacomDevicePtr priv, int touch_id)
> return;
> }
>
> - if (!common->wcmGesture)
> + if (common->wcmGestureMode == GESTURE_MULTITOUCH_MODE)
> goto ret;
>
> /* When 2 fingers are in proximity, it must always be in one of
> @@ -526,11 +529,7 @@ ret:
>
> if (common->wcmGestureMode == GESTURE_NONE_MODE && touch_id == 0)
> {
> - /* Since this is in ret block, can not rely on generic
> -* wcmGesture enable check from above.
> -*/
> - if (common->wcmGesture)
> - wcmSingleFingerTap(priv);
> + wcmSingleFingerTap(priv);
> wcmSingleFingerPress(priv);
> }
> }
> @@ -575,6 +574,9 @@ static void wcmFingerScroll(WacomDevicePtr priv)
> WacomFilterState filterd; /* borrow this struct */
> int max_spread =
> common->wcmGestureParameters.wcmMaxScrollFingerSpread;
>
> + if (!common->wcmGesture)
> + return;
> +
> getStateHistory(common, ds, ARRAY_SIZE(ds), 0);
>
> DBG(10, priv, "\n");
> @@ -672,6 +674,9 @@ static void wcmFingerZoom(WacomDevicePtr priv)
> common->wcmGestureState[1]);
> int max_spread =
> common->wcmGestureParameters.wcmMaxScrollFingerSpread;
>
> + if (!common->wcmGesture)
> + return;
> +
> getStateHistory(common, ds, ARRAY_SIZE(ds), 0);
>
> DBG(10, priv, "\n");
> --
> 1.7.12
>
>
> --
> How fast is your code?
> 3 out of 4 devs don\\\'t know how their code performs in production.
> Find out how slow your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219672;13503038;z?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> ___
> Linuxwacom-devel mailing list
> Linuxwacom-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [PATCH] Fix prerequisite check in wcmUpdateSerial
On Tue, Oct 2, 2012 at 2:53 PM, Jason Gerecke wrote:
> The prerequisite check in wcmUpdateSerial is incorrect. If the tool ID
> changes, the property reflecting it will not be updated unless/until the
> serial number also changes. The check is updated to reflect this.
>
> Additionally, the prerequesite check at one of its callsites is removed
> since the function performs the same check internally.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=45237
>
> Signed-off-by: Jason Gerecke
Nice catch! Thank you.
Reviewed-by: Ping Cheng .
Ping
> ---
> src/wcmCommon.c | 3 +--
> src/wcmXCommand.c | 2 +-
> 2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/src/wcmCommon.c b/src/wcmCommon.c
> index cb76d5a..73bdacf 100644
> --- a/src/wcmCommon.c
> +++ b/src/wcmCommon.c
> @@ -694,8 +694,7 @@ void wcmSendEvents(InputInfoPtr pInfo, const
> WacomDeviceState* ds)
> return;
> }
>
> - if (priv->cur_serial != serial || priv->cur_device_id != id)
> - wcmUpdateSerial(pInfo, serial, id);
> + wcmUpdateSerial(pInfo, serial, id);
>
> /* don't move the cursor when going out-prox */
> if (!ds->proximity)
> diff --git a/src/wcmXCommand.c b/src/wcmXCommand.c
> index c3a2a7c..d53df08 100644
> --- a/src/wcmXCommand.c
> +++ b/src/wcmXCommand.c
> @@ -925,7 +925,7 @@ wcmUpdateSerial(InputInfoPtr pInfo, unsigned int serial,
> int id)
> {
> WacomDevicePtr priv = pInfo->private;
>
> - if (priv->cur_serial == serial)
> + if (priv->cur_serial == serial && priv->cur_device_id == id)
> return;
>
> priv->cur_serial = serial;
> --
> 1.7.12.2
>
>
> --
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> ___
> Linuxwacom-devel mailing list
> Linuxwacom-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH] Fix prerequisite check in wcmUpdateSerial
The prerequisite check in wcmUpdateSerial is incorrect. If the tool ID
changes, the property reflecting it will not be updated unless/until the
serial number also changes. The check is updated to reflect this.
Additionally, the prerequesite check at one of its callsites is removed
since the function performs the same check internally.
https://bugs.freedesktop.org/show_bug.cgi?id=45237
Signed-off-by: Jason Gerecke
---
src/wcmCommon.c | 3 +--
src/wcmXCommand.c | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/wcmCommon.c b/src/wcmCommon.c
index cb76d5a..73bdacf 100644
--- a/src/wcmCommon.c
+++ b/src/wcmCommon.c
@@ -694,8 +694,7 @@ void wcmSendEvents(InputInfoPtr pInfo, const
WacomDeviceState* ds)
return;
}
- if (priv->cur_serial != serial || priv->cur_device_id != id)
- wcmUpdateSerial(pInfo, serial, id);
+ wcmUpdateSerial(pInfo, serial, id);
/* don't move the cursor when going out-prox */
if (!ds->proximity)
diff --git a/src/wcmXCommand.c b/src/wcmXCommand.c
index c3a2a7c..d53df08 100644
--- a/src/wcmXCommand.c
+++ b/src/wcmXCommand.c
@@ -925,7 +925,7 @@ wcmUpdateSerial(InputInfoPtr pInfo, unsigned int serial,
int id)
{
WacomDevicePtr priv = pInfo->private;
- if (priv->cur_serial == serial)
+ if (priv->cur_serial == serial && priv->cur_device_id == id)
return;
priv->cur_serial = serial;
--
1.7.12.2
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [PATCH 0/2] libwacom status LED helper functions
On Tue, Oct 2, 2012 at 8:09 AM, Olivier Fourdan wrote:
> The following two patches is an attempt to implement the status LED logic
> into libwacom.
>
> The logic was discussed very recently in this thread:
>http://sourceforge.net/mailarchive/message.php?msg_id=29898591
>
> and was proposed as an inclusion in GNOME settings-daemon in bug 676558:
>https://bugzilla.gnome.org/show_bug.cgi?id=676558
>
> but having the logic itself in libwacom itself makes more sense.
>
> Also please note that I don't have most of the hardware listed so the
> definitions have not been tested on all devices...
>
> Olivier Fourdan (2):
>lib: add helper functions to get LED modeswitch group
>data: update the database entry with status LED
>
> data/cintiq-21ux2.tablet |2 +
> data/cintiq-24hd.tablet |3 ++
> data/intuos4-12x19.tablet|2 +
> data/intuos4-4x6.tablet |2 +
> data/intuos4-6x9-wl.tablet |2 +
> data/intuos4-6x9.tablet |2 +
> data/intuos4-8x13.tablet |2 +
> data/intuos5-m.tablet|2 +
> data/intuos5-s.tablet|2 +
> data/intuos5-touch-l.tablet |2 +
> data/intuos5-touch-m.tablet |2 +
> data/intuos5-touch-s.tablet |2 +
> data/wacom.example |4 ++
> libwacom/libwacom-database.c |3 +-
> libwacom/libwacom.c | 70
> ++
> libwacom/libwacom.h | 16 +
> 16 files changed, 117 insertions(+), 1 deletions(-)
>
>
NAK. I agree this should go in libwacom instead of GNOME, but am not
at all sold on the "ModeswitchLED" definition. From a database
normalization standpoint it winds up duplicating data, and could be
*significantly* more flexible if written a little differently.
We already know which buttons are mode switches thanks to
"Touchstrip", "Touchstrip2", "Ring", and "Ring2". Specifying the mode
switch buttons which control LEDs duplicates data and increases the
chance of internal inconsistency. It'd be better IMHO to have
"ModeswitchLED" list the mode-switched hardware. (e.g.
ModeswtichLED=Touchstrip2;Touchstrip).
It'd take a bit more work to implement, but would not only prevent
internal inconsistency problems, it would also remove the need for my
heuristic in libwacom_get_modeswitch_led_group. If you're interested
in finding the LED group associated with a particular piece of
hardware, simply return its index in ModeswitchLED.
Of course, there's no reason to limit this to mode switches. Perhaps
in the future we release a tablet with non-modeswitch LEDs that we can
light up. For instance, a new notification light is available at
status_led0_select, with status_led{1,2}_select controlling the
touchring LEDs. We'd want something more like
"StatusLED=Notification;Ring2;Ring" to capture this. Userspace (e.g.
GNOME) would know how to drive each kind of status LED it cares about,
and can safely ignore anything it doesn't understand.
Jason
---
When you're rife with devastation / There's a simple explanation:
You're a toymaker's creation / Trapped inside a crystal ball.
And whichever way he tilts it / Know that we must be resilient
We won't let them break our spirits / As we sing our silly song.
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH 2/2] data: update the database entry with status LED
>From dd0900a74f5aa6d1c9ec0b7b556cf2f882928229 Mon Sep 17 00:00:00 2001 From: Olivier Fourdan Date: Tue, 2 Oct 2012 16:48:48 +0200 Subject: [PATCH 2/2] data: update the database entry with status LED Adds the newly supported field "ModeswitchLED" to the relevant data files. Signed-off-by: Olivier Fourdan --- data/cintiq-21ux2.tablet|2 ++ data/cintiq-24hd.tablet |3 +++ data/intuos4-12x19.tablet |2 ++ data/intuos4-4x6.tablet |2 ++ data/intuos4-6x9-wl.tablet |2 ++ data/intuos4-6x9.tablet |2 ++ data/intuos4-8x13.tablet|2 ++ data/intuos5-m.tablet |2 ++ data/intuos5-s.tablet |2 ++ data/intuos5-touch-l.tablet |2 ++ data/intuos5-touch-m.tablet |2 ++ data/intuos5-touch-s.tablet |2 ++ data/wacom.example |4 13 files changed, 29 insertions(+), 0 deletions(-) diff --git a/data/cintiq-21ux2.tablet b/data/cintiq-21ux2.tablet index 6a0b242..7141936 100644 --- a/data/cintiq-21ux2.tablet +++ b/data/cintiq-21ux2.tablet @@ -64,3 +64,5 @@ Right=K;L;M;N;J;O;P;Q;R Touchstrip=A Touchstrip2=J StripsNumModes=4 +ModeswitchLED=A;J + diff --git a/data/cintiq-24hd.tablet b/data/cintiq-24hd.tablet index 004ef22..e6bc9c7 100644 --- a/data/cintiq-24hd.tablet +++ b/data/cintiq-24hd.tablet @@ -64,3 +64,6 @@ Right=I;J;K;L;M;N;O;P Ring=A;B;C Ring2=I;J;K + +ModeswitchLED=A;B;C;I;J;K + diff --git a/data/intuos4-12x19.tablet b/data/intuos4-12x19.tablet index 4f066b6..b79eacb 100644 --- a/data/intuos4-12x19.tablet +++ b/data/intuos4-12x19.tablet @@ -54,3 +54,5 @@ OLEDs=B;C;D;E;F;G;H;I Ring=A RingNumModes=4 +ModeswitchLED=A + diff --git a/data/intuos4-4x6.tablet b/data/intuos4-4x6.tablet index 36e45d6..2dfca9d 100644 --- a/data/intuos4-4x6.tablet +++ b/data/intuos4-4x6.tablet @@ -53,3 +53,5 @@ Left=A;B;C;D;E;F;G Ring=A RingNumModes=4 +ModeswitchLED=A + diff --git a/data/intuos4-6x9-wl.tablet b/data/intuos4-6x9-wl.tablet index 90839de..c493c5d 100644 --- a/data/intuos4-6x9-wl.tablet +++ b/data/intuos4-6x9-wl.tablet @@ -54,3 +54,5 @@ OLEDs=B;C;D;E;F;G;H;I Ring=A RingNumModes=4 +ModeswitchLED=A + diff --git a/data/intuos4-6x9.tablet b/data/intuos4-6x9.tablet index 0d20933..b902f30 100644 --- a/data/intuos4-6x9.tablet +++ b/data/intuos4-6x9.tablet @@ -54,3 +54,5 @@ OLEDs=B;C;D;E;F;G;H;I Ring=A RingNumModes=4 +ModeswitchLED=A + diff --git a/data/intuos4-8x13.tablet b/data/intuos4-8x13.tablet index e46e9b4..c0c4cc9 100644 --- a/data/intuos4-8x13.tablet +++ b/data/intuos4-8x13.tablet @@ -54,3 +54,5 @@ OLEDs=B;C;D;E;F;G;H;I Ring=A RingNumModes=4 +ModeswitchLED=A + diff --git a/data/intuos5-m.tablet b/data/intuos5-m.tablet index ee3b6bb..8ddc96e 100644 --- a/data/intuos5-m.tablet +++ b/data/intuos5-m.tablet @@ -63,3 +63,5 @@ Left=A;B;C;D;E;F;G;H;I Ring=A RingNumModes=4 +ModeswitchLED=A + diff --git a/data/intuos5-s.tablet b/data/intuos5-s.tablet index 665159d..10dcfed 100644 --- a/data/intuos5-s.tablet +++ b/data/intuos5-s.tablet @@ -61,3 +61,5 @@ Left=A;B;C;D;E;F;G Ring=A RingNumModes=4 +ModeswitchLED=A + diff --git a/data/intuos5-touch-l.tablet b/data/intuos5-touch-l.tablet index cbd2685..992f5e3 100644 --- a/data/intuos5-touch-l.tablet +++ b/data/intuos5-touch-l.tablet @@ -63,3 +63,5 @@ Left=A;B;C;D;E;F;G;H;I Ring=A RingNumModes=4 +ModeswitchLED=A + diff --git a/data/intuos5-touch-m.tablet b/data/intuos5-touch-m.tablet index 4cd57a8..db9ecd4 100644 --- a/data/intuos5-touch-m.tablet +++ b/data/intuos5-touch-m.tablet @@ -63,3 +63,5 @@ Left=A;B;C;D;E;F;G;H;I Ring=A RingNumModes=4 +ModeswitchLED=A + diff --git a/data/intuos5-touch-s.tablet b/data/intuos5-touch-s.tablet index 6e3812e..6593708 100644 --- a/data/intuos5-touch-s.tablet +++ b/data/intuos5-touch-s.tablet @@ -61,3 +61,5 @@ Left=A;B;C;D;E;F;G Ring=A RingNumModes=4 +ModeswitchLED=A + diff --git a/data/wacom.example b/data/wacom.example index 762c360..692f45e 100644 --- a/data/wacom.example +++ b/data/wacom.example @@ -144,3 +144,7 @@ Touchstrip2=J # We assume the same number of modes for each of the touchstrips # if there is more than one StripsNumModes=4 + +# If the device has LED for mode toggling buttons +# like on the Cintiq 21UX2 and Intuos4/5 +ModeswitchLED=A;J -- 1.7.1 -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH 1/2] lib: add helper functions to get LED modeswitch group
>From 24cb3733ebc40c96a8bad7384797c50f64f49be6 Mon Sep 17 00:00:00 2001
From: Olivier Fourdan
Date: Tue, 2 Oct 2012 16:39:11 +0200
Subject: [PATCH 1/2] lib: add helper functions to get LED modeswitch group
Adds a new field "ModeswitchLED" to the libwacom
database definition file to specify which buttons
feature a usable status LED for current mode.
Adds a libwacom_get_modeswitch_led_group() helper
function to compute which status LED is to use for
the given button. If a device has only one ring/strip,
use LED 0 otherwise the left ring/strip is controlled
by LED 1 and the right ring/strip by LED 0.
Also adds a convenient libwacom_get_num_rings()
to match the similar libwacom_get_num_strips().
Signed-off-by: Olivier Fourdan
---
libwacom/libwacom-database.c |3 +-
libwacom/libwacom.c | 70 ++
libwacom/libwacom.h | 16 +
3 files changed, 88 insertions(+), 1 deletions(-)
diff --git a/libwacom/libwacom-database.c b/libwacom/libwacom-database.c
index 5468975..6d8d4d4 100644
--- a/libwacom/libwacom-database.c
+++ b/libwacom/libwacom-database.c
@@ -243,7 +243,8 @@ struct {
{ "Ring2", WACOM_BUTTON_RING2_MODESWITCH },
{ "Touchstrip", WACOM_BUTTON_TOUCHSTRIP_MODESWITCH },
{ "Touchstrip2", WACOM_BUTTON_TOUCHSTRIP2_MODESWITCH },
- { "OLEDs", WACOM_BUTTON_OLED }
+ { "OLEDs", WACOM_BUTTON_OLED },
+ { "ModeswitchLED", WACOM_BUTTON_MODESWITCH_LED }
};
static void
diff --git a/libwacom/libwacom.c b/libwacom/libwacom.c
index fe850a2..55d1ff2 100644
--- a/libwacom/libwacom.c
+++ b/libwacom/libwacom.c
@@ -540,6 +540,19 @@ static void print_button_flag_if(int fd, WacomDevice *device, const char *label,
dprintf(fd, "\n");
}
+static void print_buttons_led_for_device (int fd, WacomDevice *device)
+{
+ int nbuttons = libwacom_get_num_buttons(device);
+ char b;
+ int led_group;
+
+ for (b = 'A'; b < 'A' + nbuttons; b++) {
+ led_group = libwacom_get_modeswitch_led_group (device, b);
+ if (led_group >= 0)
+ dprintf(fd, "Button%c = LED group %d\n", b, led_group);
+ }
+}
+
static void print_buttons_for_device (int fd, WacomDevice *device)
{
int nbuttons = libwacom_get_num_buttons(device);
@@ -556,8 +569,10 @@ static void print_buttons_for_device (int fd, WacomDevice *device)
print_button_flag_if(fd, device, "Touchstrip", WACOM_BUTTON_TOUCHSTRIP_MODESWITCH);
print_button_flag_if(fd, device, "Touchstrip2", WACOM_BUTTON_TOUCHSTRIP2_MODESWITCH);
print_button_flag_if(fd, device, "OLEDs", WACOM_BUTTON_OLED);
+ print_button_flag_if(fd, device, "ModeswitchLED", WACOM_BUTTON_MODESWITCH_LED);
print_button_flag_if(fd, device, "Ring", WACOM_BUTTON_RING_MODESWITCH);
print_button_flag_if(fd, device, "Ring2", WACOM_BUTTON_RING2_MODESWITCH);
+ print_buttons_led_for_device (fd, device);
dprintf(fd, "RingNumModes=%d\n", libwacom_get_ring_num_modes(device));
dprintf(fd, "Ring2NumModes=%d\n", libwacom_get_ring2_num_modes(device));
dprintf(fd, "StripsNumModes=%d\n", libwacom_get_strips_num_modes(device));
@@ -749,6 +764,16 @@ const int *libwacom_get_supported_styli(WacomDevice *device, int *num_styli)
return device->supported_styli;
}
+int libwacom_get_num_rings(WacomDevice *device)
+{
+ if (device->features & FEATURE_RING2)
+ return 2;
+ if (device->features & FEATURE_RING)
+ return 1;
+
+ return 0;
+}
+
int libwacom_has_ring(WacomDevice *device)
{
return !!(device->features & FEATURE_RING);
@@ -779,6 +804,51 @@ int libwacom_get_strips_num_modes(WacomDevice *device)
return device->strips_num_modes;
}
+int libwacom_get_modeswitch_led_group (WacomDevice *device,
+ char button)
+{
+ int index;
+ int num_rings;
+ int num_strips;
+
+ g_return_val_if_fail (device->num_buttons > 0, -1);
+ g_return_val_if_fail (button >= 'A', -1);
+ g_return_val_if_fail (button < 'A' + device->num_buttons, -1);
+
+ index = button - 'A';
+
+ if (!(device->buttons[index] & WACOM_BUTTON_MODESWITCH) ||
+ !(device->buttons[index] & WACOM_BUTTON_MODESWITCH_LED))
+ return -1;
+
+ /*
+ * The rule to determine the status LED to use is as follow:
+ *
+ * "[...] if a device has only one ring/strip, use status_led0_select;
+ * otherwise the left ring/strip is controlled by status_led1_select
+ * and the right ring/strip by status_led0_select."
+ *
+ * http://sourceforge.net/mailarchive/message.php?msg_id=29898591
+ */
+
+ num_rings = libwacom_get_num_rings (device);
+ num_strips = libwacom_get_num_strips (device);
+
+ if (((num_rings == 1) && (device->buttons[index] & WACOM_BUTTON_RING_MODESWITCH)) ||
+ ((num_rings == 2) && (device->buttons[index] & WACOM_BUTTON_RING2_MODESWITCH)))
+ return 0;
+
+ if (((num_strips == 1) && (device->buttons[index] & WACOM_BUTTON_TOUCHSTRIP_MODESWITCH)) ||
+ ((num_strips == 2) && (device->buttons[index] & WACOM_BUTTON_TOUCHSTRIP2_MODESWITCH)))
+ return 0;
+
+ if (((num_rings == 2) && (device->buttons[index] & WACOM_BUTTON_RING_MODESWITCH)) ||
+ ((num_strips == 2) && (device->butt
[Linuxwacom-devel] [PATCH 0/2] libwacom status LED helper functions
The following two patches is an attempt to implement the status LED logic into libwacom. The logic was discussed very recently in this thread: http://sourceforge.net/mailarchive/message.php?msg_id=29898591 and was proposed as an inclusion in GNOME settings-daemon in bug 676558: https://bugzilla.gnome.org/show_bug.cgi?id=676558 but having the logic itself in libwacom itself makes more sense. Also please note that I don't have most of the hardware listed so the definitions have not been tested on all devices... Olivier Fourdan (2): lib: add helper functions to get LED modeswitch group data: update the database entry with status LED data/cintiq-21ux2.tablet |2 + data/cintiq-24hd.tablet |3 ++ data/intuos4-12x19.tablet|2 + data/intuos4-4x6.tablet |2 + data/intuos4-6x9-wl.tablet |2 + data/intuos4-6x9.tablet |2 + data/intuos4-8x13.tablet |2 + data/intuos5-m.tablet|2 + data/intuos5-s.tablet|2 + data/intuos5-touch-l.tablet |2 + data/intuos5-touch-m.tablet |2 + data/intuos5-touch-s.tablet |2 + data/wacom.example |4 ++ libwacom/libwacom-database.c |3 +- libwacom/libwacom.c | 70 ++ libwacom/libwacom.h | 16 + 16 files changed, 117 insertions(+), 1 deletions(-) -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] libwacom: libwacom_is_builtin() misleading?
On Tue, 2012-10-02 at 15:20 +0200, Olivier Fourdan wrote: > Hi all, > > While reviewing the libwacom API, I realized that > libwacom_is_builtin() could be misleading: > >/** > * @param device The tablet to query > * @return non-zero if the device is built-in or zero if the device > is an > * external tablet > */ >int libwacom_is_builtin(WacomDevice *device); > > From the description, I would expect built-in tablets (such as the > one used for Tablet PC) to have that set to true, and all other > external tablet to have that property set to false. > > Actually, what libwacom_is_builtin() means is that the tablet is a > screen tablet, so all Cintiq have that property set to true, even > though these are actually external tablets. Built-in means that the tablet is built into the screen. Feel free to change the documentation if it's not clear. Cheers -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] libwacom: libwacom_is_builtin() misleading?
Hi all, While reviewing the libwacom API, I realized that libwacom_is_builtin() could be misleading: /** * @param device The tablet to query * @return non-zero if the device is built-in or zero if the device is an * external tablet */ int libwacom_is_builtin(WacomDevice *device); From the description, I would expect built-in tablets (such as the one used for Tablet PC) to have that set to true, and all other external tablet to have that property set to false. Actually, what libwacom_is_builtin() means is that the tablet is a screen tablet, so all Cintiq have that property set to true, even though these are actually external tablets. Problem is in some cases it would interesting to tell if a tablet is actually built-in or external (for example to set the TabletPC mode automatically) and using libwacom_is_builtin() is not appropriate for that. While I understand all built-in tablets are screen tablets, not all screen tablets are built-in IMHO. Is that my own interpration of the above which is wrong or is it the function name/description which is misleading? And if it's the function name, any idea on how we could fix this nicely? GNOME setttings daemon does use libwacom_is_builtin() to determine if a tablet is a screen tablet (e.g. Cintiq). Cheers Olivier. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
