On Tue, Oct 2, 2012 at 8:09 AM, Olivier Fourdan <ofour...@redhat.com> 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
