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 Fourdanofour...@redhat.com 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] 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)
Hi Ping Ping Cheng said the following on 09/28/2012 10:08 PM: On Fri, Sep 28, 2012 at 12:21 AM, Olivier Fourdanofour...@redhat.com wrote: Ping Cheng said the following on 09/27/2012 10:56 PM: 1. OSD can and will be enabled for tablets with and without LED, as long as the tablet supports expresskeys; Yes, absolutely, this is to help with Expresskeys assigned functions, independently of LED or even OLED. Great. Then, do you plan to add OSD pie menu to mock up LED functions/features for tablets without LEDs? The pie menu (or [...] Actually no, it's not the pie menu that I have in mind, it's the small OSD window representing only the touch ring showing the current mode being selected and associated bindings (but of course the final word always belong to gnome-design team in this regard ;-) ) something like that in your term) should look the same as the ones for tablets with LEDs. In fact, with OSD, LED is unnecessary, at least at desktop level. LEDs can still be very useful indicators in other cases though. My goal for now is to get a usable OSD asap, something very similar to what is already proposed in GNOME bugzilla but with a less simple, more accurate layout. FYI, C22HD does not have LEDs. But it has two round buttons at the same places where the LEDs are for Cintiq 21UX2. So, same OSD menu that works for C21UX2 could work for C22HD without LEDs. Let me know if you don't get what I am talking about. I think I get it, but... :-) Basically, it means the two hav the same button layout but the 22HD does nto have LED, is that correct? A bit of search on Google images gives: Cintiq 22HD: http://cdn.slashgear.com/wp-content/uploads/2012/07/Wacom_Cintiq_22HD-580x453.jpg Cintiq 21UX2 http://mybroadband.co.za/news/wp-content/uploads/wacom_cintiq_21UX_2_613786268.jpg Cheers, Olivier -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? 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] RFC: Back to the tablet buttons representation (aimed at making an OSD window for the Expresskeys)
Hi Ping, Ping Cheng said the following on 09/27/2012 10:56 PM: Yes, it makes sense to me. I have no Gnome design or impl experience. So, I can not tell which format is better. But your OSD video looks good. Can I assume? 1. OSD can and will be enabled for tablets with and without LED, as long as the tablet supports expresskeys; Yes, absolutely, this is to help with Expresskeys assigned functions, independently of LED or even OLED. 2. OSD can be disabled in g-c-c; OSD is there, but if not triggered, it's won't come up. * Is it simple enough? Or too simplistic? I like simple solutions. Ditto. The simpler the better (as long as it works of course ;-) ) * Is SVG appropriate for that? Do we actually need an accurate image of the buttons? The images displayed in your video are very good. We know if they are for the square or round buttons. * Assuming it makes sense, what unit should be used for the position/size of elements? I guess it depends on the size of the screen? For opaque tablets, such as Intuos and Bamboo series, your video of mapping it to the screen/primary monitor is very good. For LCD tablets, such as Cintiq series, OSD would be displayed close to the actual buttons, I think. Makes sense, this is where the buttons size and positioning will help. * 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? Per side of tablet since users would most likely use different settings for different side. Talking about per side, rotation should be considered for all sides if there are more than one set of buttons. Oh it is, even now, my question was more about the coordinates for the buttons. What I have in mind is to define 4 blocks of buttons, one per side, and locate the buttons relative to these blocks so that it's remains independent of the overall size. I would really like to move forward with this, while at the same time keeping things simple enough. I am with you. I hope we can get something simple and straightforward in Gnome soon. Ping BTW, this code from [1] does not fit what I understood + * - First ring (group 0) uses LED 0 + * - Second ring (group 1) uses LED 1 + * - First touchstrip (group 2) uses LED 1 + * - Second touchstrip (group 3) uses LED 0 There are two cases, tablet has one set of expresskeys; and tablet has two sets of expresskeys. If there is only one set of expresskeys, ring or touchstrip will and can only use LED 0; If there are two sets of expresskeys, the left set (i.e., your first ring/touchstrip) uses LED 1; the right set, your second ring/touchstrip, uses LED 0. [1] https://bugzilla.gnome.org/attachment.cgi?id=214732action=edit Ah, you read my mind, that was my very next step! :-D I'll start another thread for this to keep things on topic. Cheers, Olivier. -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? 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] RFC: Back to the tablet buttons representation (aimed at making an OSD window for the Expresskeys)
Hi Jason, Jason Gerecke said the following on 09/28/2012 12:19 AM: On Thu, Sep 27, 2012 at 2:32 AM, Olivier Fourdanofour...@redhat.com 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... * 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. -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? 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] RFC: Back to the tablet buttons representation (aimed at making an OSD window for the Expresskeys)
On Fri, Sep 28, 2012 at 12:21 AM, Olivier Fourdan ofour...@redhat.com wrote: Ping Cheng said the following on 09/27/2012 10:56 PM: 1. OSD can and will be enabled for tablets with and without LED, as long as the tablet supports expresskeys; Yes, absolutely, this is to help with Expresskeys assigned functions, independently of LED or even OLED. Great. Then, do you plan to add OSD pie menu to mock up LED functions/features for tablets without LEDs? The pie menu (or something like that in your term) should look the same as the ones for tablets with LEDs. In fact, with OSD, LED is unnecessary, at least at desktop level. LEDs can still be very useful indicators in other cases though. FYI, C22HD does not have LEDs. But it has two round buttons at the same places where the LEDs are for Cintiq 21UX2. So, same OSD menu that works for C21UX2 could work for C22HD without LEDs. Let me know if you don't get what I am talking about. 2. OSD can be disabled in g-c-c; OSD is there, but if not triggered, it's won't come up. How do we trigger OSD? I guess by a button. Which button do you plan to use? * 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? Per side of tablet since users would most likely use different settings for different side. Talking about per side, rotation should be considered for all sides if there are more than one set of buttons. Oh it is, even now, my question was more about the coordinates for the buttons. What I have in mind is to define 4 blocks of buttons, one per side, and locate the buttons relative to these blocks so that it's remains independent of the overall size. Works for me. One concern for fixed blocks though is they could be too small for large monitors (e.g., Cintiq24HD) or too large for small screens (7 inch tablet). Two or three sets of these blocks may be needed. We can get to the details when we test on different systems/setups. Thank you for your effort. Ping -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? 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] RFC: Back to the tablet buttons representation (aimed at making an OSD window for the Expresskeys)
On Thu, Sep 27, 2012 at 2:32 AM, Olivier Fourdan ofour...@redhat.com 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? ;-) Yes, it makes sense to me. I have no Gnome design or impl experience. So, I can not tell which format is better. But your OSD video looks good. Can I assume? 1. OSD can and will be enabled for tablets with and without LED, as long as the tablet supports expresskeys; 2. OSD can be disabled in g-c-c; * Is it simple enough? Or too simplistic? I like simple solutions. * Is SVG appropriate for that? Do we actually need an accurate image of the buttons? The images displayed in your video are very good. We know if they are for the square or round buttons. * Assuming it makes sense, what unit should be used for the position/size of elements? I guess it depends on the size of the screen? For opaque tablets, such as Intuos and Bamboo series, your video of mapping it to the screen/primary monitor is very good. For LCD tablets, such as Cintiq series, OSD would be displayed close to the actual buttons, I think. * 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? Per side of tablet since users would most likely use different settings for different side. Talking about per side, rotation should be considered for all sides if there are more than one set of buttons. I would really like to move forward with this, while at the same time keeping things simple enough. I am with you. I hope we can get something simple and straightforward in Gnome soon. Ping BTW, this code from [1] does not fit what I understood +* - First ring (group 0) uses LED 0 +* - Second ring (group 1) uses LED 1 +* - First touchstrip (group 2) uses LED 1 +* - Second touchstrip (group 3) uses LED 0 There are two cases, tablet has one set of expresskeys; and tablet has two sets of expresskeys. If there is only one set of expresskeys, ring or touchstrip will and can only use LED 0; If there are two sets of expresskeys, the left set (i.e., your first ring/touchstrip) uses LED 1; the right set, your second ring/touchstrip, uses LED 0. [1] https://bugzilla.gnome.org/attachment.cgi?id=214732action=edit -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Linuxwacom-devel mailing list
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 1:56 PM, Ping Cheng pingli...@gmail.com wrote: On Thu, Sep 27, 2012 at 2:32 AM, Olivier Fourdan ofour...@redhat.com 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? ;-) Yes, it makes sense to me. I have no Gnome design or impl experience. So, I can not tell which format is better. But your OSD video looks good. Can I assume? 1. OSD can and will be enabled for tablets with and without LED, as long as the tablet supports expresskeys; 2. OSD can be disabled in g-c-c; * Is it simple enough? Or too simplistic? I like simple solutions. * Is SVG appropriate for that? Do we actually need an accurate image of the buttons? The images displayed in your video are very good. We know if they are for the square or round buttons. * Assuming it makes sense, what unit should be used for the position/size of elements? I guess it depends on the size of the screen? For opaque tablets, such as Intuos and Bamboo series, your video of mapping it to the screen/primary monitor is very good. For LCD tablets, such as Cintiq series, OSD would be displayed close to the actual buttons, I think. * 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? Per side of tablet since users would most likely use different settings for different side. Talking about per side, rotation should be considered for all sides if there are more than one set of buttons. I would really like to move forward with this, while at the same time keeping things simple enough. I am with you. I hope we can get something simple and straightforward in Gnome soon. Ping BTW, this code from [1] does not fit what I understood +* - First ring (group 0) uses LED 0 +* - Second ring (group 1) uses LED 1 +* - First touchstrip (group 2) uses LED 1 +* - Second touchstrip (group 3) uses LED 0 There are two cases, tablet has one set of expresskeys; and tablet has two sets of expresskeys. If there is only one set of expresskeys, ring or touchstrip will and can only use LED 0; If there are two sets of expresskeys, the left set (i.e., your first ring/touchstrip) uses LED 1; the right set, your second ring/touchstrip, uses LED 0. [1] https://bugzilla.gnome.org/attachment.cgi?id=214732action=edit Not to get off-topic, but do we want to consider revising this interface to make it more logical? Having the first ring/strip being controlled by the second LED control (and vice versa) rubs me the wrong way. I'd consider it a bug, except that its the documented behavior. I'm not sure it qualifies as a
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 3:20 PM, Jason Gerecke killert...@gmail.com wrote: On Thu, Sep 27, 2012 at 1:56 PM, Ping Cheng pingli...@gmail.com wrote: BTW, this code from [1] does not fit what I understood +* - First ring (group 0) uses LED 0 +* - Second ring (group 1) uses LED 1 +* - First touchstrip (group 2) uses LED 1 +* - Second touchstrip (group 3) uses LED 0 There are two cases, tablet has one set of expresskeys; and tablet has two sets of expresskeys. If there is only one set of expresskeys, ring or touchstrip will and can only use LED 0; If there are two sets of expresskeys, the left set (i.e., your first ring/touchstrip) uses LED 1; the right set, your second ring/touchstrip, uses LED 0. [1] https://bugzilla.gnome.org/attachment.cgi?id=214732action=edit Not to get off-topic, but do we want to consider revising this interface to make it more logical? Having the first ring/strip being controlled by the second LED control (and vice versa) rubs me the wrong way. I'd consider it a bug, except that its the documented behavior. I'm not sure it qualifies as a grave error that Dmitry would allow to be changed, but it'd make more sense to fix it in the kernel than to rely on libwacom to describe the quirk. I think we are not talking the same thing. Maybe I didn't make myself clear. Let me try it again. I meant the four lines should read something like: +* - First ring (group 0) uses LED 1 +* - Second ring (group 1) uses LED 0 +* - First touchstrip (group 2) uses LED 1 +* - Second touchstrip (group 3) uses LED 0 That is, no matter it is ring or touchstrip, the one in the first group should use LED 1, the one in the second group uses LED 0. The kernel driver is consistent in this sense. And this is for tablets with two sets of LEDs. If there is only one set of LEDs, such as Intuos 4 and 5, only LED 0 can be used. Ping -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
