Re: [Linuxwacom-devel] GNOME Wacom panel implementation questions
On Thu, Feb 02, 2012 at 06:54:23PM +, Bastien Nocera wrote: Heya, Instead of hitting just Peter with this sort of question[1], I'm guessing that there are quite a few people on the list that could answer my questions (or point me to the relevant Wiki pages). For the fun that's about to be had with the Intuos4 LEDs, a couple of questions: - is there/will there be a way to avoid getting/updating/setting all the LEDs when changing one? What format do the LEDs graphics needs to be in? I think this was mentioned in another thread but LEDs are the little ones next to the ring and OLEDs are the ones that can display pretty pictures. I don't really have a good idea on the OLED approach yet. From a driver's POV the best approach may be to set a property to a Pixmap, with the driver the converting to the actual format the kernel wants. There are plenty of tools that can convert from $FILEFORMAT to pixmap, and IIRC we had a xsetwacom patch for this at some point. - can wacom provide a library of pixmaps for us to use for the LEDs, so that they look like they already do on Windows or MacOS X, or would we have the time consuming task of re-doing them? If the problem is simply that the data isn't easily available, we can certainly try and nab it from the other drivers. - will we need to handle rotation ourselves, and rotate the LED drawings ourselves? yes, whatever triggers the rotation should rotate the OLEDs. - what metadata does one need to associate a button with an LED placement? I'm not sure what you mean here, can you elaborate? - Any ideas what a sane API would look like (eg. if you didn't have to use device properties, how would you have implemented it? :) if it's for libwacom, I'd prefer a simple path-based API that you point to the png. -How does one grab events from the touchring when used with the stylus? xev refuses to show anything. Cheers [1]: Instead I get him to check whether we support all 22 mouse buttons on the Cintiq 21UX2 :) https://bugs.freedesktop.org/show_bug.cgi?id=45557 fixed :) Cheers, Peter -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] GNOME Wacom panel implementation questions
On Wed, Feb 8, 2012 at 9:28 AM, Peter Hutterer peter.hutte...@who-t.net wrote: On Thu, Feb 02, 2012 at 06:54:23PM +, Bastien Nocera wrote: Heya, Instead of hitting just Peter with this sort of question[1], I'm guessing that there are quite a few people on the list that could answer my questions (or point me to the relevant Wiki pages). For the fun that's about to be had with the Intuos4 LEDs, a couple of questions: - is there/will there be a way to avoid getting/updating/setting all the LEDs when changing one? What format do the LEDs graphics needs to be in? I think this was mentioned in another thread but LEDs are the little ones next to the ring and OLEDs are the ones that can display pretty pictures. I don't really have a good idea on the OLED approach yet. From a driver's POV the best approach may be to set a property to a Pixmap, with the driver the converting to the actual format the kernel wants. There are plenty of tools that can convert from $FILEFORMAT to pixmap, and IIRC we had a xsetwacom patch for this at some point. - can wacom provide a library of pixmaps for us to use for the LEDs, so that they look like they already do on Windows or MacOS X, or would we have the time consuming task of re-doing them? If the problem is simply that the data isn't easily available, we can certainly try and nab it from the other drivers. - will we need to handle rotation ourselves, and rotate the LED drawings ourselves? yes, whatever triggers the rotation should rotate the OLEDs. - what metadata does one need to associate a button with an LED placement? I'm not sure what you mean here, can you elaborate? If/when you guys get to the touch ring LED's, I'd like to jump in. Maybe the above metadata question is related to following. I'm a little interested in the click button in the center of it and how it affects an LED (not OLED). The LED's represent a mode of ring. What the exact mode means I think is an application specific issue but toggling between modes and how it changes LED's is probably something like g-s-d's job. The good news is that the sysfs interface for this LED is also mode based. You can only light 1 LED at a time. What I'd like you guys to consider is simple tablets that do not have touch rings nor the related mode LEDs. It would be nice if you could assign any random button on tablet to be a more generic mode feature. The mode feature is something like increasing a # between 0-2 each time button is pressed with a roll over at max value. By default on Intuos and Cintiq, libwacom would say that ring button is for mode feature but for a Bamboo it would say no button is. Hopefully, we have a GUI that allows user to pick one of Bamboo's 4 buttons for mode feature though. In Intous/Cintiq case, the mode would also control a sysfs LED. For Bamboo, there is no LED nor sysfs entry but the current mode could be monitored via DBUS/gsettings/X property/etc and we could make an applet to show virtual LED like those capslock LED applets when that is missing. The mode LED is meant to track how touch ring's scroll events are treated (zoom, scroll, brush size, etc) but I don't see why we couldn't use it for any random mode concept such as airbrush vs. pen vs. eraser modes. Basically, a way of increasing the # of ExpressKey's your tablet has. Just some thoughts I had. Chris -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] GNOME Wacom panel implementation questions
On Wed, 2012-02-08 at 10:42 -0600, Chris Bagwell wrote: On Wed, Feb 8, 2012 at 9:28 AM, Peter Hutterer peter.hutte...@who-t.net wrote: On Thu, Feb 02, 2012 at 06:54:23PM +, Bastien Nocera wrote: Heya, Instead of hitting just Peter with this sort of question[1], I'm guessing that there are quite a few people on the list that could answer my questions (or point me to the relevant Wiki pages). For the fun that's about to be had with the Intuos4 LEDs, a couple of questions: - is there/will there be a way to avoid getting/updating/setting all the LEDs when changing one? What format do the LEDs graphics needs to be in? I think this was mentioned in another thread but LEDs are the little ones next to the ring and OLEDs are the ones that can display pretty pictures. I don't really have a good idea on the OLED approach yet. From a driver's POV the best approach may be to set a property to a Pixmap, with the driver the converting to the actual format the kernel wants. There are plenty of tools that can convert from $FILEFORMAT to pixmap, and IIRC we had a xsetwacom patch for this at some point. - can wacom provide a library of pixmaps for us to use for the LEDs, so that they look like they already do on Windows or MacOS X, or would we have the time consuming task of re-doing them? If the problem is simply that the data isn't easily available, we can certainly try and nab it from the other drivers. - will we need to handle rotation ourselves, and rotate the LED drawings ourselves? yes, whatever triggers the rotation should rotate the OLEDs. - what metadata does one need to associate a button with an LED placement? I'm not sure what you mean here, can you elaborate? If/when you guys get to the touch ring LED's, I'd like to jump in. Maybe the above metadata question is related to following. I'm a little interested in the click button in the center of it and how it affects an LED (not OLED). The LED's represent a mode of ring. What the exact mode means I think is an application specific issue but toggling between modes and how it changes LED's is probably something like g-s-d's job. The good news is that the sysfs interface for this LED is also mode based. You can only light 1 LED at a time. What I'd like you guys to consider is simple tablets that do not have touch rings nor the related mode LEDs. It would be nice if you could assign any random button on tablet to be a more generic mode feature. The mode feature is something like increasing a # between 0-2 each time button is pressed with a roll over at max value. By default on Intuos and Cintiq, libwacom would say that ring button is for mode feature but for a Bamboo it would say no button is. Hopefully, we have a GUI that allows user to pick one of Bamboo's 4 buttons for mode feature though. In Intous/Cintiq case, the mode would also control a sysfs LED. For Bamboo, there is no LED nor sysfs entry but the current mode could be monitored via DBUS/gsettings/X property/etc and we could make an applet to show virtual LED like those capslock LED applets when that is missing. The mode LED is meant to track how touch ring's scroll events are treated (zoom, scroll, brush size, etc) but I don't see why we couldn't use it for any random mode concept such as airbrush vs. pen vs. eraser modes. Basically, a way of increasing the # of ExpressKey's your tablet has. I have no plans on exposing modes for devices that don't have the LEDs to show which mode is selected. The code is still there for you to modify if you want though. Modifying your tablet's definition might be sufficient to achieve that in the future. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH] Exclude HID_LOGITECH_DJ from compiling
A new option appeared in drivers/hid/Makefile. We don't want to compile that module as it has nothing to do with Wacom. Signed-off-by: Przemo Firszt prz...@firszt.eu --- wacom-kernel/Makefile |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/wacom-kernel/Makefile b/wacom-kernel/Makefile index f9af575..35f93ff 100644 --- a/wacom-kernel/Makefile +++ b/wacom-kernel/Makefile @@ -70,6 +70,7 @@ WACOMBTCFG := \ CONFIG_HID_LCPOWER=n\ CONFIG_HID_LOGITECH=n\ CONFIG_LOGITECH_FF=n\ + CONFIG_HID_LOGITECH_DJ=n\ CONFIG_LOGIRUMBLEPAD2_FF=n\ CONFIG_LOGIG940_FF=n\ CONFIG_LOGIWII_FF=n\ -- 1.7.6.4 -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
