Re: [Linuxwacom-devel] [PATCH v2 5/5] Export wireless tablet's device match info to sysfs

[Chris Bagwell]

On Fri, Mar 28, 2014 at 2:20 PM, Paul A. Tessier phern...@gmail.com wrote:
 From: Paul A. Tessier phern...@gmail.com

 adds new sysfs ro attribute dev_match to wireless interfaces

 This will be need by libwacom to know which actual tablet is connected
 to the wireless kit

 Changes since v1:
  - fixed bad attribute permission DEV_ATTR_RO - DEV_ATTR_RO_PERM


FYI on above Changes.   Its kinda a pain to do the right way but
convention is not to put a patch's changelog in the commit message
since it loses its value the minute its commited to repo.  Instead,
you need to hand edit the patch file and add the text after the ---
below and before the next --- that starts the patch.  Git ignores
all that text when you do a git am to apply the patch and so readers
can see it but it will not go into commit.

Sometimes people will instead put the change log in that 0/5 message
if they are resending the whole series.

 Signed-off-by: Paul A. Tessier phern...@gmail.com
 ---
  3.7/wacom_sys.c | 36 
  1 file changed, 32 insertions(+), 4 deletions(-)

 diff --git a/3.7/wacom_sys.c b/3.7/wacom_sys.c
 index 6c28e78..071ad1e 100644
 --- a/3.7/wacom_sys.c
 +++ b/3.7/wacom_sys.c
 @@ -999,6 +999,18 @@ static DEVICE_ATTR(name##_timer, DEV_ATTR_RW_PERM,   
   \
  DEVICE_WIRELESS_TIMER_ATTR(sleep, SLEEP);
  DEVICE_WIRELESS_TIMER_ATTR(powersave, POWERSAVE);

 +static ssize_t wacom_wireless_dev_match_show(struct device *dev,
 +struct device_attribute *attr,
 +char *buf)
 +{
 +   struct wacom *wacom = dev_get_drvdata(dev);
 +   return scnprintf(buf, PAGE_SIZE, %04x:%04x\n, USB_VENDOR_ID_WACOM,
 +wacom-wacom_wac.pid);
 +}
 +
 +static DEVICE_ATTR(dev_match, DEV_ATTR_RO_PERM, 
 wacom_wireless_dev_match_show,
 +  NULL);
 +
  static struct attribute *wireless_attrs[] = {
 dev_attr_sleep_timer.attr,
 dev_attr_powersave_timer.attr,
 @@ -1246,8 +1258,12 @@ static void wacom_unregister_wireless(struct wacom 
 *wacom)
  {
 struct wacom_features *wacom_features = wacom-wacom_wac.features;

 -   if (!(wacom_features-quirks  WACOM_QUIRK_WIRELESS_KIT) ||
 -   wacom_features-device_type != BTN_TOOL_PEN)
 +   if (!(wacom_features-quirks  WACOM_QUIRK_WIRELESS_KIT))
 +   return;
 +
 +   device_remove_file(wacom-intf-dev, dev_attr_dev_match);
 +
 +   if (wacom_features-device_type != BTN_TOOL_PEN)
 return;

 sysfs_remove_group(wacom-intf-dev.kobj,
 @@ -1260,8 +1276,18 @@ static int wacom_register_wireless(struct wacom *wacom)
 struct wacom_features *wacom_features = wacom_wac-features;
 int error;

 -   if (!(wacom_features-quirks  WACOM_QUIRK_WIRELESS_KIT) ||
 -   wacom_features-device_type != BTN_TOOL_PEN)
 +   if (!(wacom_features-quirks  WACOM_QUIRK_WIRELESS_KIT))
 +   return 0;
 +
 +   error = device_create_file(wacom-intf-dev, dev_attr_dev_match);
 +   if (error) {
 +   dev_err(wacom-intf-dev,
 +   cannot create 'dev_match' sysfs file: err %d\n,
 +   error);
 +   return error;
 +   }
 +
 +   if(wacom_features-device_type != BTN_TOOL_PEN)
 return 0;

 wacom-wireless.sleep_timer = WWK_SLEEP_DEFAULT;
 @@ -1375,6 +1401,7 @@ static void wacom_wireless_work(struct work_struct 
 *work)
 wacom_wac1-shared-touch_max = 
 wacom_wac1-features.touch_max;
 wacom_wac1-shared-type = wacom_wac1-features.type;
 wacom_wac1-features.quirks |= WACOM_QUIRK_WIRELESS_KIT;
 +   wacom_wac1-pid = wacom_wac-pid;
 error = wacom_register(wacom1);
 if (error)
 goto fail;
 @@ -1394,6 +1421,7 @@ static void wacom_wireless_work(struct work_struct 
 *work)
 snprintf(wacom_wac2-name, WACOM_NAME_MAX,
  %s (WL) 
 Pad,wacom_wac2-features.name);
 wacom_wac2-features.quirks |= 
 WACOM_QUIRK_WIRELESS_KIT;
 +   wacom_wac2-pid = wacom_wac-pid;
 error = wacom_register(wacom2);
 if (error)
 goto fail;
 --
 1.8.3.2


 --
 ___
 Linuxwacom-devel mailing list
 Linuxwacom-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test  Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees_APR

Re: [Linuxwacom-devel] [PATCH 2/5] Support crop mark LEDs

[Chris Bagwell]

On Fri, Mar 28, 2014 at 11:37 AM, Paul A. Tessier phern...@gmail.com wrote:
 From: Paul A. Tessier phern...@gmail.com

 adds sysfs attribute wacom_led/crop_marks_luminance
 adds support for crop marks in led control message
 adds script to exercise LEDs

 Signed-off-by: Paul A. Tessier phern...@gmail.com
 ---
  3.7/wacom.h |  1 +
  3.7/wacom_sys.c |  5 +++-
  test/cycle-leds | 71 
 +

This test script is probably a good thing to have in input-wacom but
for the future patch to linux-input to merge into kernel, I'm sure
they will not want that script submitted.

Just an FYI.

Chris

  3 files changed, 76 insertions(+), 1 deletion(-)
  create mode 100755 test/cycle-leds

 diff --git a/3.7/wacom.h b/3.7/wacom.h
 index b79d451..19ab360 100644
 --- a/3.7/wacom.h
 +++ b/3.7/wacom.h
 @@ -121,6 +121,7 @@ struct wacom {
 u8 llv;   /* status led brightness no button (1..127) */
 u8 hlv;   /* status led brightness button pressed 
 (1..127) */
 u8 img_lum;   /* OLED matrix display brightness */
 +   u8 crop_lum;  /* crop marks led brightness (1..127) */
 } led;
 struct power_supply battery;
  };
 diff --git a/3.7/wacom_sys.c b/3.7/wacom_sys.c
 index 255a398..e0311a5 100644
 --- a/3.7/wacom_sys.c
 +++ b/3.7/wacom_sys.c
 @@ -732,7 +732,7 @@ static int wacom_led_control(struct wacom *wacom)
  */
 int ring_led = wacom-led.select[0]  0x03;
 int ring_lum = (((wacom-led.llv  0x60)  5) - 1)  0x03;
 -   int crop_lum = 0;
 +   int crop_lum = (((wacom-led.crop_lum  0x60)  5) - 1)  
 0x03;

 buf[0] = WAC_CMD_LED_CONTROL;
 buf[1] = (crop_lum  4) | (ring_lum  2) | (ring_led);
 @@ -880,6 +880,7 @@ static DEVICE_ATTR(name##_luminance, DEV_ATTR_RW_PERM,
   \

  DEVICE_LUMINANCE_ATTR(status0, llv);
  DEVICE_LUMINANCE_ATTR(status1, hlv);
 +DEVICE_LUMINANCE_ATTR(crop_marks, crop_lum);
  DEVICE_LUMINANCE_ATTR(buttons, img_lum);

  static ssize_t wacom_button_image_store(struct device *dev, int button_id,
 @@ -952,6 +953,7 @@ static struct attribute_group intuos4_led_attr_group = {

  static struct attribute *intuos5_led_attrs[] = {
 dev_attr_status0_luminance.attr,
 +   dev_attr_crop_marks_luminance.attr,
 dev_attr_status_led0_select.attr,
 NULL
  };
 @@ -1002,6 +1004,7 @@ static int wacom_initialize_leds(struct wacom *wacom)
 wacom-led.select[1] = 0;
 wacom-led.llv = 32;
 wacom-led.hlv = 0;
 +   wacom-led.crop_lum = 32;
 wacom-led.img_lum = 0;

 error = sysfs_create_group(wacom-intf-dev.kobj,
 diff --git a/test/cycle-leds b/test/cycle-leds
 new file mode 100755
 index 000..89b46cd
 --- /dev/null
 +++ b/test/cycle-leds
 @@ -0,0 +1,71 @@
 +#!/bin/bash
 +err()
 +{
 +  echo $@ 2
 +  exit 1
 +}
 +
 +set_led()
 +{
 +  echo $1  $led_sel
 +}
 +set_rng()
 +{
 +#  echo $(expr $1 \* 32 )  $rng_lum
 +  echo $1  $rng_lum
 +}
 +set_crp()
 +{
 +#  echo $(expr $1 \* 32 )  $crp_lum
 +  echo $1  $crp_lum
 +}
 +
 +if [ -z $1 ]; then
 +   loc=$(find /sys/ -name wacom_led)
 +   [ ! -d $loc ]  err no wacom_led found in /sys/
 +else
 +   loc=$1
 +   [ ! -d $loc ]  err not a folder: $1
 +fi
 +
 +led_sel=$loc/status_led0_select
 +rng_lum=$loc/status0_luminance
 +crp_lum=$loc/crop_marks_luminance
 +
 +[ ! -f $led_sel ]  err no led selector found: $led_sel
 +[ ! -f $rng_lum ]  err no ring leds found: $rng_lum
 +[ ! -f $crp_lum ]  err no crop leds found: $crp_lum
 +
 +old_led=$(cat $led_sel)
 +old_rng=$(cat $rng_lum)
 +old_crp=$(cat $crp_lum)
 +
 +set_led 0
 +set_crp 0
 +set_rng 0
 +
 +for j in {0..1}; do
 +  for i in {1..127}; do
 +set_crp $i
 +  done
 +  for i in {126..0}; do
 +set_crp $i
 +  done
 +done
 +
 +for k in {0..3}; do
 +  set_led $k
 +  for j in {0..1}; do
 +for i in {1..127}; do
 +  set_rng $i
 +done
 +for i in {126..0}; do
 +  set_rng $i
 +done
 +  done
 +done
 +
 +set_led $old_led
 +set_crp $old_crp
 +set_rng $old_rng
 +
 --
 1.8.3.2


 --
 ___
 Linuxwacom-devel mailing list
 Linuxwacom-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test  Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees_APR
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH] Add an option to disable pressure recalibration

[Chris Bagwell]

On Fri, Feb 14, 2014 at 4:07 AM, Egbert Eich e...@freedesktop.org wrote:
 Jason Gerecke writes:
   On Thu, Feb 13, 2014 at 2:10 PM, Peter Hutterer
   peter.hutte...@who-t.net wrote:
On Wed, Feb 12, 2014 at 08:04:07PM +0100, Egbert Eich wrote:
From: Egbert Eich e...@suse.com
   
If the initial pressure of a device is != 0 the driver recalibrates
the pressure range. This is to account for worn out devices.
The downside is that when the user hits the tablet very hard the
initial pressure reading may be unequal to zero even for a perfectly
good pen. If the consecutive pressure readings are not higher than
the initial pressure by a threshold no button event will be generated.
This option allows to disable the recalibration.
   
can we be smarter about this? e.g. disable worn-out pen detection once a
tool has shown that it repeatedly sent events below the threshold. I 
 don't
think an option is the right way to go here, with the driver and desktop
environments repeatedly interfering with each other I'm hesitant to add
options for something that we could probably solve for the 90% use-case.

 Peter, I thought about this but wasn't able to come up with a satisfactory 
 solution
 for the use case I had to deal with. Point is, we don't keep a history for 
 the pens
 we see. Whenever a pen comes into proximity it is treated like a new pen once
 it goes out of proximity it is forgotten.
 Let me give a bit more insight on the use case I'm dealing with:
 These Wacom tablets are used for air traffic controlling - you may remember 
 XDC
 in Toulouse where we visited a  development center for air traffic control
 software.
 Here pens are only used for klicking and dragging. Thus the pressure 
 information
 is never evaluated by software, it is only used to synthesize klick events in
 the driver.
 Moreover air traffic controllers do not use pens like artists do: in 
 situations
 with heavy traffic it happens that the controller taps the pen quite fast and
 hard.
 This is what happens then: the pen comes from far away, thus is out of 
 proximity.
 It will come into proximity, immediately have a non-zero pressure reading 
 then,
 when the hand pulls back quickly, it will go out of proximity again.
 Here the tablet will frequently only get a single pressure event sent 
 immediately
 when the pen comes into proximity Here recalibration kicks in and no click
 will be generated.
 In this situation we have too little data to determine if the pen is worn or 
 not.
 Moreover, what will happen in this situation is what will always happen in 
 such
 situations:
 in order to trigger a press event the pen will be hit against the tablet even
 harder only exaggerating the problem.
 Thus for air traffic safety it is a requirement that pressure recalibration 
 can be
 turned off.
 Instead pens will be exchanged routinely and in situations where the logs 
 indicate
 they are worn.

Here is my suggestion for a slightly smarter priv-minPressure.
First, instead updating priv-minPressure the whole time pen is in
proximity (via rebasePressure()), we could have that routine store in
priv-minPressureSeen instead.  Storing history seems to be common
theme.  We could then move updating priv-minPressure to only when
going out of proximity.

That delayed reaction should account of above use case.  Although one
might slam down a pen with speed, I suspect average case is to pull up
with a lot less speed... so your likely to get enough samples to have
accurate low pressure.

Also, this gives us a nice time period to log a message as well.  If
priv-min_pressure  X then log_once(likely have worn tip.  consider
replacing);

comon-wcmThreshold may be a good starting point for what X should
be.  If we never see a value below that and table claims a maxZ value
then likely warn tip.

The main negative: upon first connection of tablet and first stroke of
pen, your pressure will be very high until you go out of prox.  For
very first proximity cycle, we could probably fall back to todays
behavior and make min be what ever it was at first proximity.


  
   Agreed.
  
   Based on how the pressure transducer works, I would think that a drop
   in pressure of more than a few percent should be a clear indication
   that the pen isn't simply worn out. Once its clear that the user has
   triggered this condition, we could send the click and temporarily
   disable remapping. If we wanted to get fancy, we could remember the
   last good pressure that the pen entered with and use that value for
   remapping instead.
  

 I've thought about a similar scenario already and I'm happy to explore
 if the algorithm can be designed a bit smarter ie if it has initially
 recalibrated and thus not synthesized a pressure event but later detects
 that the pressure falls below the initial pressure by more than 10 percent
 the 'dropped' klick event will 'emulated' if the pressure readings
 meets the threshold criteria.
 I have not 

Re: [Linuxwacom-devel] [input-wacom PATCH 01/10] Scan all children connected to the parent hub

[Chris Bagwell]

OK, that was the type of info I was looking for... which were the changes
were related to features lacking in older kernels.

They all seemed reasonable to me with maybe the exception of Android
patch.  For the ones that don't have a Reviewed-by, you can go ahead and
add my:

Acked-by: Chris Bagwell ch...@cnpbagwell.com


Chris



On Fri, Sep 27, 2013 at 1:32 PM, Jason Gerecke killert...@gmail.com wrote:

 On Fri, Sep 27, 2013 at 10:35 AM, Chris Bagwell ch...@cnpbagwell.com
 wrote:
  Hi Jason,
 
  I'd be happy to review these patches if you want it but can you give a
  little more context for the series on them?
 
  For example, a version of this patch seems to be in linux kernel but uses
  usb_hub_for_each_child().  Can patch be aligned with linux?
 
  Are other patches in linux kernel as well?  Any that are not and so
 should
  be reviewed closer?
 
  Chris

 Sure thing - I should have sent a summary but it skipped my mind.

 This patchset has two halves. The first half (patches 01-05) covers
 the Cintiq Companion Hybrid, and the second half (06-10) the Intuos
 Pro. Support for both devices has been merged upstream, but this set
 contains a few other fixup patches that aren't upstream. The patches
 which haven't gone through upstream review are:

 01/10 - Back when I wrote `wacom_get_sibling`, I was under the
 impression that the list of child devices connected to a hub
 (`dev-parent-children`) was compact and would have only NULL
 entries after the last child. It turns out this isn't the case and
 that if the hub isn't fully populated you can have NULL entries in the
 middle of the list. This is the case with the hub internal to the
 Cintiq Companion Hybrid: a NULL child sits between the pen and touch
 sensors, which was preventing `wacom_get_sibling` from actually
 linking the two devices. As you've noticed, upstream uses
 `usb_hub_for_each_child` now. This was introduced in 3.7 along with a
 change that removed the ability for drivers to directly access the
 `dev-parent-children` list. Forward-porting this patch is
 impossible, and backporting `usb_hub_for_each_child` is a little
 unreasonable IMO.

 03/10 - This is a patch included in the kernel shipping with the
 Cintiq Companion Hybrid which works around an issue Android had
 correctly interpreting the device type. ABS_MT_TOOL_TYPE isn't
 declared upstream anyway, so I figure its safe to remove from
 input-wacom as well.

 04/10 - Another Android-specific patch. ABS_MISC contains pen serial
 number information, but because it is declared with min==max==0
 Android ignores it and prevents us from passing it along to apps. To
 work around this, we instead declare that ABS_MISC can take on any
 value from INT_MIN to INT_MAX, which I think is more correct anyway.
 Do note, however, that this patch has been rejected upstream!

 09/10 - While testing the Intuos Pro, I noticed some weird behavior
 under CentOS 6. The touch interface was being detected as an EMR,
 complete with stylus/eraser/pad suite of tools rather than just the
 expected finger tool. From what I could tell, the fact that we didn't
 properly declare BTN_TOOL_FINGER et.al. in
 `wacom_setup_input_capabilities` was to blame. Changing this fixed the
 detection, but touch still didn't work correctly until I noticed
 `wacom_wac_irq` was incorrectly sending touch packets to
 `wacom_intuos_irq`. I could have fixed these in patch 08/10 where the
 Intuos Pro support is added, but since the exact same problems also
 affected the Intuos5 I thought it would be clearer to implement the
 pro identically at first and then fix both of the simultaneously.

 10/10 - I was having trouble with the touch interface under 2.6.38+ on
 older Fedora and Ubuntu releases and found that xf86-input-wacom was
 ignoring the touch device since the ABS_X and ABS_Y axes weren't being
 declared. They still don't seem to be explicitly declared in 3.7+ (or
 upstream) but the two axes do show up as being supported in evtest. I
 think there might be something inside the MT protocol's single-touch
 emulation functions that is doing this, but I honestly can't find
 where (which makes me a little nervous).

 Jason
 ---
 Now instead of four in the eights place /
 you’ve got three, ‘Cause you added one  /
 (That is to say, eight) to the two, /
 But you can’t take seven from three,/
 So you look at the sixty-fours

 
 
 
  On Wed, Sep 25, 2013 at 6:50 PM, Jason Gerecke killert...@gmail.com
 wrote:
 
  Instead of bailing at the first NULL child (i.e., the first non-
  connected port), go through all ports and simply skip any NULL
  children. This condition occurs in the Cintiq Companion Hybrid
  when trying to locate the other half (i.e. pen or touch device)
  of the tablet.
 
  Signed-off-by: Jason Gerecke killert...@gmail.com
  ---
   2.6.38/wacom_sys.c | 17 ++---
   1 file changed, 10 insertions(+), 7 deletions(-)
 
  diff --git a/2.6.38/wacom_sys.c b/2.6.38/wacom_sys.c
  index 177efd8..6848717 100644

Re: [Linuxwacom-devel] [input-wacom PATCH 01/10] Scan all children connected to the parent hub

[Chris Bagwell]

Hi Jason,

I'd be happy to review these patches if you want it but can you give a
little more context for the series on them?

For example, a version of this patch seems to be in linux kernel but uses
usb_hub_for_each_child().  Can patch be aligned with linux?

Are other patches in linux kernel as well?  Any that are not and so should
be reviewed closer?

Chris



On Wed, Sep 25, 2013 at 6:50 PM, Jason Gerecke killert...@gmail.com wrote:

 Instead of bailing at the first NULL child (i.e., the first non-
 connected port), go through all ports and simply skip any NULL
 children. This condition occurs in the Cintiq Companion Hybrid
 when trying to locate the other half (i.e. pen or touch device)
 of the tablet.

 Signed-off-by: Jason Gerecke killert...@gmail.com
 ---
  2.6.38/wacom_sys.c | 17 ++---
  1 file changed, 10 insertions(+), 7 deletions(-)

 diff --git a/2.6.38/wacom_sys.c b/2.6.38/wacom_sys.c
 index 177efd8..6848717 100644
 --- a/2.6.38/wacom_sys.c
 +++ b/2.6.38/wacom_sys.c
 @@ -622,7 +622,7 @@ static DEFINE_MUTEX(wacom_udev_list_lock);

  static struct usb_device *wacom_get_sibling(struct usb_device *dev, int
 vendor, int product)
  {
 -   struct usb_device **sibling;
 +   int i;

 if (vendor == 0  product == 0)
 return dev;
 @@ -630,14 +630,17 @@ static struct usb_device *wacom_get_sibling(struct
 usb_device *dev, int vendor,
 if (dev-parent == NULL)
 return NULL;

 -   sibling = dev-parent-children;
 -   while (sibling != NULL  *sibling != NULL) {
 -   struct usb_device_descriptor d = (*sibling)-descriptor;
 +   for (i = 0 ; i  dev-parent-maxchild; i++) {
 +   struct usb_device *sibling = dev-parent-children[i];
 +   struct usb_device_descriptor d;

 -   if (d.idVendor == vendor  d.idProduct == product)
 -   return *sibling;
 +   if (sibling == NULL)
 +   continue;
 +
 +   d = sibling-descriptor;

 -   sibling++;
 +   if (d.idVendor == vendor  d.idProduct == product)
 +   return sibling;
 }

 return NULL;
 --
 1.8.4



 --
 October Webinars: Code for Performance
 Free Intel webinars can help you accelerate application performance.
 Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
 from
 the latest Intel processors and coprocessors. See abstracts and register 
 http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk
 ___
 Linuxwacom-devel mailing list
 Linuxwacom-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] Supporting Wacom pen tablet model CTL-471

[Chris Bagwell]

On Wed, Aug 14, 2013 at 12:05 PM, Arjuna Rao Chavala
arjunar...@gmail.comwrote:

 Hi,

 I recently purchased CTL-471/K Wacom Pen Tablet (Bamboo One) (Sl.No
 3CFP002700). The active area size is 152*94 mm (6*3.7in) and the tablet has
 stylus with rocker switch. The device is identified as with lsusb
 Bus 003 Device 003: ID 056a:0300 Wacom Co ltd.


 I tried to set it up on my Ubuntu 12.04 LTS system with
 3.2.0-51-generic-pae Kernel and X.Org X Server 1.11.3. It did not work.


 I updated the wacom kernel  from my Ubuntu sources and updated it as shown
 below.
 { USB_DEVICE_WACOM(0xDD) },
 { USB_DEVICE_WACOM(0x0300) },/* CTL-471/K/
 { USB_DEVICE_WACOM(0xDE) },

 static const struct wacom_features wacom_features_0xDD =
 { Wacom Bamboo Connect, WACOM_PKGLEN_BBPEN, 14720,  9200,
 1023,
   31, BAMBOO_PT, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
 /* CTL-471/K support*/
 static const struct wacom_features wacom_features_0x0300 =
 { Wacom Bamboo One, WACOM_PKGLEN_BBPEN, 14720,  9200, 1023,
   31, BAMBOO_PT, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
 static const struct wacom_features wacom_features_0xDE =
 { Wacom Bamboo 16FG 4x5, WACOM_PKGLEN_BBPEN,14720,  9200,
 1023,
   31, BAMBOO_PT, WACOM_INTUOS_RES, WACOM_INTUOS_RES };



This seems reasonable based on what I see on Wacom's webpage.  I'd guess it
would be close to the Bamboo Connect (0xDD).  From Wacom's web page they
look exactly the same and have same specs and same price.  Not sure whats
different.


 and  
xf86-input-wacomhttp://sourceforge.net/apps/mediawiki/linuxwacom/index.php?title=Xf86-input-wacom
 along with  patch at
 http://forums.linuxmint.com/viewtopic.php?f=42t=110408#p652097 The diff
 file is enclosed.

 I Installed the new kernel and new xf86-input-wacom, but found the system
 crashing when tablet is connected.

 Am I missing anything?


There should be no reason to modify the xf86-input-wacom driver.  It should
just work as long as kernel driver correctly fills in above values and
advertises them.

Try reverting to unmodified xf86 and see if crashing stops.

At minimum, you need this change from your current patch.  You used a
usbBamboo1 structure when you should be using usbBamboo.  The other
things in your xf86-input-wacom can easily be source of crashes.

Chris



 Thanks
 Arjuna




 --
 Get 100% visibility into Java/.NET code with AppDynamics Lite!
 It's a free troubleshooting tool designed for production.
 Get down to code-level detail for bottlenecks, with 2% overhead.
 Download for free and get started troubleshooting in minutes.
 http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
 ___
 Linuxwacom-devel mailing list
 Linuxwacom-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel


--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] Improve support for Bamboo Fun CTH-661/L

[Chris Bagwell]

On Wed, Jan 23, 2013 at 8:08 AM, Pander pan...@users.sourceforge.netwrote:

 Hi all,

 I would like to improve the support for Bamboo Fun CTH-661-SE-NL which
 is also known as CTH-661/L with USB ID 056a:00db. It is a special
 edition and the NL in the name stands for Netherlands.

 An image and English specifications can be found here:


 http://www.tablet4u.eu/product/en/bamboo-se-pen-touch-medium-nl.html?SetLanguage=ENG

 The right-handed orientation looks like this:
   http://beltehno.by/pics/items/52118_big.jpg
 The left-handed orientation is of course 180 degrees rotated.

 I have some questions that can improve the support for this model.

 1) This model has already been included in usb.ids, modules.usbmap and
 wcmUSB.c last year. Should it also be listed in wcmValidateDevice.c?

 2) Should this model also be listed in
 69-xserver-xorg-input-wacom.rules? (P.S. Lines 75-77 do not line up with
 the other lines.)


Here is some info on your 1st two questions.

There should be no need to update wcmValidateDevice.c.  Tracking USB ID's
in X  input driver was a temporary work around for time period when kernel
drivers were not able to publish enough information about their
capabilities.  For these multi-touch Bamboo's, the kernel driver publishes
all needed info.

The need to touch any user-land USB files or X config files is kinda a
distro specific question.  In recent Fedora releases, I can plug in a
previously unknown USB Bamboo device and xf86-input-wacom will readily use
it with no manual configuration... as long as Kernel driver exists for it.

Some distro's will not create the /dev/input items correctly if it doesn't
have a USB id listed in a config file.  Maybe your running into that.

Chris
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] finger lag on Wacom ISDv4 E6

[Chris Bagwell]

My guess is your at close to the expected rate; based on those numbers.
100 Hz, 133 Hz, and 200 Hz are some common sample rates used by
digitizers.  If I recall correctly, Microsoft established 133 Hz as minimum.

The alternating 8/12ms is throwing me so I'm not sure if your HW is trying
for 100 Hz or 133 Hz.  Googling thinkpad tablet 133 pps turns up more
hits than value of 100 so I assume it probably should be 8ms consistently.
So you might be able to find 2-3ms savings on kernel side somewhere.  I
don't have any guesses were that'd come from.

If I recall correctly, the Intuous tablets can be set to 100, 133, or 200
sample rates and then send at that fixed rate; with all other tablets
sending at 1 fixed sample rate in that 133 Hz range.

If your window drags really feel off then I suspect there are improvements
to be made outside kernel.

Chris

On Sun, Jan 13, 2013 at 1:38 AM, Bobby Powers bobbypow...@gmail.com wrote:

 Hi folks,

 I've recently acquired a Thinkpad x230t, which has a Wacom touchscreen
 (vendor/product: 056a:00e6).

 When moving my finger around quickly on the screen (especially evident
 when dragging a window around in X) there is a noticeable lag.  I
 added some debugging statements in wacom_wac.c:wacom_tpc_mt_touch()
 and verified that the lag is visible at the kernel level, rather than
 being some X vsync artifact or something.

 I then noticed that my debugging printk's were being called every 8 or
 12 milliseconds, alternating:
 [14265.968153 0.011958] wacom 2-1.5:1.1: wacom_tpc_mt_touch: x:
 1580, y: 783
 [14265.976128 0.007975] wacom 2-1.5:1.1: wacom_tpc_mt_touch: x:
 1589, y: 790
 [14265.988148 0.012020] wacom 2-1.5:1.1: wacom_tpc_mt_touch: x:
 1599, y: 798
 [14265.996128 0.007980] wacom 2-1.5:1.1: wacom_tpc_mt_touch: x:
 1610, y: 806
 [14266.008023 0.011895] wacom 2-1.5:1.1: wacom_tpc_mt_touch: x:
 1622, y: 814
 [14266.016000 0.007977] wacom 2-1.5:1.1: wacom_tpc_mt_touch: x:
 1633, y: 822
 [14266.027994 0.011994] wacom 2-1.5:1.1: wacom_tpc_mt_touch: x:
 1645, y: 831

 (`dmesg -d` is what reports the delta)

 It seems like others have reported similar[1].  The endpoint interval
 for the Finger interface is 5 frames, which I believe translates to 5
 ms (I'm new to the USB stack, please correct any errors I have!):

 [13496.745718] wacom: endpoint interval: 7
 [13496.745784] input: Wacom ISDv4 E6 Pen
 /devices/pci:00/:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.0/input/input38
 [13496.750724] wacom: endpoint interval: 5
 [13496.750815] input: Wacom ISDv4 E6 Finger as
 /devices/pci:00/:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.1/input/input39


 And I see the wacom driver initializes a single URB, which re-submits
 itself at the end of it's callback, which seems to be the common
 idiom.

 I guess I'm looking to see if there is anything I can do to try to get
 data faster/with less lag from the device (can I try manually
 decreasing endpoint-bInterval, or will that just cause
 instability/Bad Things?), or how I would debug this in a better way.
 Let me know what additional data I can provide as well.

 thanks!

 yours,
 Bobby


 1 -
 http://old.nabble.com/Pen-Cursor-lag-on-Wacom-on-Asus-Slate-ep121-to32360422.html


 --
 Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
 MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
 with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
 MVPs and experts. ON SALE this month only -- learn more at:
 http://p.sf.net/sfu/learnmore_123012
 ___
 Linuxwacom-devel mailing list
 Linuxwacom-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH 3/4 v2] Send generic PAD events before other events

[Chris Bagwell]

On Sun, Dec 16, 2012 at 11:35 PM, Ping Cheng pingli...@gmail.com wrote:

 On Sunday, December 16, 2012, Ping Cheng wrote:

 On Sunday, December 16, 2012, Chris Bagwell wrote:


 On Sun, Dec 16, 2012 at 7:17 PM, Ping Cheng pingli...@gmail.com wrote:

 On Sun, Dec 16, 2012 at 1:40 PM, Chris Bagwell ch...@cnpbagwell.comwrote:




 On Thu, Dec 13, 2012 at 2:18 PM, Ping Cheng pingli...@gmail.comwrote:

 If we wait until we finish other verifications, we could miss
 PAD events since they will be filtered out when there are no
 motion events sent simultaneously.



 Signed-off-by: Ping Cheng pingli...@gmail.com
 Acked-by: Jason Gerecke killert...@gmail.com
 ---
  src/wcmUSB.c |   13 +
  1 file changed, 13 insertions(+)

 diff --git a/src/wcmUSB.c b/src/wcmUSB.c
 index 0ea2093..f15a6a2 100644
 --- a/src/wcmUSB.c
 +++ b/src/wcmUSB.c
 @@ -1655,6 +1655,19 @@ static void usbDispatchEvents(InputInfoPtr
 pInfo)
 {
 usbParseKeyEvent(common, event, channel);
 usbParseBTNEvent(common, event,
 private-wcmBTNChannel);
 +
 +   /* send PAD events now for generic devices.
 Otherwise,
 +* they are filtered out when there are no
 motion events.
 +*/
 +   if ((common-wcmProtocolLevel ==
 WCM_PROTOCOL_GENERIC)
 +   
 (common-wcmChannel[private-wcmBTNChannel].dirty))
 +{
 +   DBG(10, common, Dirty flag set on
 channel %d; 
 +   sending event.\n,
 private-wcmBTNChannel);
 +
 common-wcmChannel[private-wcmBTNChannel].dirty = FALSE;
 +   wcmEvent(common,
 private-wcmBTNChannel,
 +
  common-wcmChannel[private-wcmBTNChannel].work);
 +   }



 I don't understand this one.  How are they filtered out?  Is
 usbDispatchEvents() returning early or is it some other function?


 It is returned immediarely by the next if statement since both
 device_type and proximity are zero when no touch events.


 I see.  Now I can understand why you had patch 1/4 as well.

 The intent was that the button channel's ds-device_type and
 ds-proximity is fixed and initialized one time up front by
 usbWcmInitPadState(). That function was added specifically because its
 known that no BTN_TOOL_* like event will kick the code to set up PAD's
 device_type and proximity for generic devices.

 The code in 1/4  patch was being to agressive and setting these fields
 to zero and then confusing all kinds of stuff from there.  If we submit
 patch 1/4 then can this patch be dropped?  Does it do anything useful once
 device_type and proximity stay at good values for PAD?


 I can not sleep well without getting the job done ;-).

 No, we can not drop this patch. Although type and prox are good for PAD,
 ds will never be on PAD channel for generic devices. We do not know if
 there are touch events from a packet or not until after we parsed the
 packet. So, calling wcmEvent immediately is the best option if we do not
 want to go through all the other channels here.


I see what your saying now by ds will not be PAD channel but I still don't
think think duplicating the event dispatch logic is correct way forward.
We should either 1) fix usbChooseChannel() so that it is choosing the
correct channel as PAD channel by peaking into the events or the simpler 2)
make ds point to PAD channel any time we detect button events.  Here is
modification of your patch:

+
+   /* Generic protocol will not send a BTN_TOOL_* or
serial # when only
+* a PAD button is sent and usbChooseChannel() will
choose wrong.
+* Force ds to button channel when detected to
handle this case.
+*/
+   if ((common-wcmProtocolLevel ==
WCM_PROTOCOL_GENERIC)
+(common-wcmChannel[private-
wcmBTNChannel].dirty))
+{
+ds =
common-wcmChannel[private-wcmBTNChannel].work;
+dslast =
common-wcmChannel[private-wcmBTNChannel].valid.state;
+   }

Since ds is now pointing at PAD instead of uninitialized channel 0, the
if() block will stop incorrectly executing, and the wcmEvent() logic will
only have a single code path to maintain.

Although we will also be resetting ds pointer for Movement+PAD events as
well; it should be no problem since we just need it pointing at any one of
the two valid and initialized ds fields.


 Chris, can I assume your Acked/Reviewed-by for the patch set?


I've Reviewed-by 2 of the 4.  Do you agree with above change to patch?
I'll add my Reviewed-by to that version.  I also have 1 more comment for
1/4 that I'll reply to.

Chris



 Ping


  I can tell from the if() that its a Generic device... which one though?


 All generic devices that support PAD the new

Re: [Linuxwacom-devel] [PATCH 1/4 v2] Remove channel duplication code for generic devices

[Chris Bagwell]

On Sun, Dec 16, 2012 at 10:34 PM, Ping Cheng pingli...@gmail.com wrote:

 Hi Chris,

 Thank you for your reply and your comments. Most importantly, thank you
 for your time.

 The patch does not have to be merged. Let's figure out if the duplicated
 channel is necessary or not.


 On Sun, Dec 16, 2012 at 2:56 PM, Chris Bagwell ch...@cnpbagwell.comwrote:


 On Thu, Dec 13, 2012 at 2:16 PM, Ping Cheng pingli...@gmail.com wrote:

 We use true MT protocol for MT devices in kernel now. This code
 was introduced to deal with ABS_TOOL_*TAP events loss issue. It
 is uncessary any more. And its existence makes it hard to support
 generic PAD cleanly.


 I can't think of any negative effects removing these will do with
 protocol 4 and generic devices with MT events using the latest input-wacom
 drivers.  There is the theoritical issue the code is solving so if its
 possible to solve what ever the bug is without deleting this then that
 would be my preference.

 Since I don't know exact issue your seeing, I can't really comment on if
 its a good idea to delete this.

 If you do decide to delete this logic


 We can keep this logic. But it does not provide the information required
 for generic device any more.


After discussing 3/4, I see now we need some form of this patch.  We can
either delete this logic or keep it *but* save off device_type and
proximity and restore it after the structure copy.  Maybe need serial # to.

I'm OK with either solution since I have no known issue it solves... except
for next comment.


 For P5 devices, we do not use it anyway.

 The theoritical issues only happen:

 if incoming tool lands on outgoing tool's axes, As you mentioned we deal
 with absolute values, this case is hard to happen, plus ignoring the first
 motion events would avoid this issue;

 if user pressing a button while bringing tool out of prox, then pressing
 the same button while bringing it back in. In this case, we want to send
 the last button up since we do not know if the tool is going to come back
 or not.

 In both cases, duplicated channel is unnecessary.


 then I'd say we official do not support the *old* 2 finger drivers and so
 I'd delete the Protocol 4 DOUBLETAP and TRIPLETAP logic in wcmUSB.c and
 wcmValidateDevice.c as part of this patch as well.


 Those TAP code are used by ISDV4 touch devices, which I can not afford to
 delete.


 Touchpad's using old drivers but without this code become close to
 un-usable with all the cursor jumping that occurs.


 Which old driver are we talking about, in input-wacom or in old kernel
 releases? Which versions?

 The current 2.6.30 kernel driver for bamboo in input-wacom is un-usable
 with the current xf86-input-wacom. We have to use xf86-input-synaptics. I
 thought that was on purpose.



Oh yeah, I got part of that wrong.  We must keep DOUBLETAP logic.  Its the
TRIPLETAP that I'm worried about.  If any of the old drivers are used that
sends TRIPLETAP then it needs the logic that this patch is attempting to
delete to be somewhat usable (meaning your cursor doesn't constantly make
wild jumps).

I'd prefer to get rid of TRIPLETAP support in xf86-input-wacom *even* *if*
older kernels may be sending it since 1) it improves code readability, 2)
TRIPLETAP has known issues that xf86-input-wacom could never fully work
around and 3) removing code from xf86-input-wacom doesn't break working
with those older kernel drivers, it just removes second finger touch
support which you've mentioned is already broke anyways in current
xf86-input-wacom.

If you want to keep this version of patch (deleting logic), do you mind
also deleting lines 304-307 in wcmValidateDevice.c and 1343-1357 in
wcmUSB.c?  That should be all thats needed to remove support for old style
TRIPLETAP.

Chris



 Ping




 Chris


 Signed-off-by: Ping Cheng pi...@wacom.com
 Acked-by: Jason Gerecke killert...@gmail.com
 ---
 v2: only patch 2/4 has code change from Jason's comments. To ease the
 review
 and merge effort, I updated all to v2 with acked-by and reviewed-by tags.
 ---
  src/wcmUSB.c |   34 ++
  1 file changed, 2 insertions(+), 32 deletions(-)

 diff --git a/src/wcmUSB.c b/src/wcmUSB.c
 index e192489..4b5f53b 100644
 --- a/src/wcmUSB.c
 +++ b/src/wcmUSB.c
 @@ -37,7 +37,6 @@ typedef struct {
 Bool wcmPenTouch;
 Bool wcmUseMT;
 int wcmMTChannel;
 -   int wcmPrevChannel;
 int wcmEventCnt;
 struct input_event wcmEvents[MAX_USB_EVENTS];
 int nbuttons;/* total number of buttons */
 @@ -1601,11 +1600,8 @@ static void usbDispatchEvents(InputInfoPtr pInfo)
 return;
 }

 -   /* Protocol 5 devices have some complications related to
 DUALINPUT
 -* support and can not use below logic to recover from input
 -* event filtering.  Instead, just live with occasional dropped
 -* event.  Since tools are dynamically assigned a channel #, the
 -* structure must

Re: [Linuxwacom-devel] [PATCH 4/4 v2] BTN_TOOL_FINGER is not for PAD if MT is supported

[Chris Bagwell]

On Thu, Dec 13, 2012 at 2:19 PM, Ping Cheng pingli...@gmail.com wrote:

 BTN_TOOL_FINGER indicates single touch/first finger if MT is enabled

 Signed-off-by: Ping Cheng pi...@wacom.com
 Reviewed-by: Jason Gerecke killert...@gmail.com


Oh, good point.  I assume the new Intuos5's are tracked as Protocol 5
devices but also with MT.

 If this is true then probably all the checks for WCM_PROTOCOL_GENERIC in
wcmUSB.c need to be reviewed.

Reviewed-by: Chris Bagwell ch...@cnpbagwell.com


---
  src/wcmUSB.c |   13 -
  1 file changed, 8 insertions(+), 5 deletions(-)

 diff --git a/src/wcmUSB.c b/src/wcmUSB.c
 index ef19b51..1f1db35 100644
 --- a/src/wcmUSB.c
 +++ b/src/wcmUSB.c
 @@ -1441,13 +1441,15 @@ static void usbParseBTNEvent(WacomCommonPtr common,
   * Translates a tool code from the kernel (e.g. BTN_TOOL_PEN) into the
   * corresponding device type for the driver (e.g. STYLUS_ID).
   *
 + * @param[in] common
   * @param[in] type  Linux input tool type (e.g. EV_KEY)
   * @param[in] code  Linux input tool code (e.g. BTN_STYLUS_PEN)
 - * @param[in] protocol  Wacom protocol type (e.g. WCM_PROTOCOL_GENERIC)
   * @return  Wacom device ID (e.g. STYLUS_ID) or 0 if no match.
   */
 -static int toolTypeToDeviceType(int type, int code, int protocol)
 +static int toolTypeToDeviceType(WacomCommonPtr common, int type, int code)
  {
 +   wcmUSBData* private = common-private;
 +
 if (type == EV_KEY) {
 switch(code) {
 case BTN_TOOL_PEN:
 @@ -1457,7 +1459,8 @@ static int toolTypeToDeviceType(int type, int code,
 int protocol)
 return STYLUS_ID;

 case BTN_TOOL_FINGER:
 -   if (protocol != WCM_PROTOCOL_GENERIC)
 +   if ((common-wcmProtocolLevel !=
 WCM_PROTOCOL_GENERIC)
 +!private-wcmUseMT)
 return PAD_ID;
 else
 return TOUCH_ID;
 @@ -1499,7 +1502,7 @@ static int refreshDeviceType(WacomCommonPtr common)
 for (i = 0; i  KEY_MAX; i++)
 {
 if (ISBITSET(keys, i))
 -   device_type = toolTypeToDeviceType(EV_KEY, i,
 common-wcmProtocolLevel);
 +   device_type = toolTypeToDeviceType(common, EV_KEY,
 i);
 if (device_type)
 return device_type;
 }
 @@ -1529,7 +1532,7 @@ static int usbInitToolType(WacomCommonPtr common,
 const struct input_event *even

 for (i = 0; (i  nevents)  !device_type; ++i, event_ptr++)
 {
 -   device_type = toolTypeToDeviceType(event_ptr-type,
 event_ptr-code, common-wcmProtocolLevel);
 +   device_type = toolTypeToDeviceType(common,
 event_ptr-type, event_ptr-code);
 }

 if (!device_type)
 --
 1.7.10.4



 --
 LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
 Remotely access PCs and mobile devices and provide instant support
 Improve your efficiency, and focus on delivering more value-add services
 Discover what IT Professionals Know. Rescue delivers
 http://p.sf.net/sfu/logmein_12329d2d
 ___
 Linuxwacom-devel mailing list
 Linuxwacom-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH 1/4 v2] Remove channel duplication code for generic devices

[Chris Bagwell]

On Thu, Dec 13, 2012 at 2:16 PM, Ping Cheng pingli...@gmail.com wrote:

 We use true MT protocol for MT devices in kernel now. This code
 was introduced to deal with ABS_TOOL_*TAP events loss issue. It
 is uncessary any more. And its existence makes it hard to support
 generic PAD cleanly.


I can't think of any negative effects removing these will do with protocol
4 and generic devices with MT events using the latest input-wacom drivers.
There is the theoritical issue the code is solving so if its possible to
solve what ever the bug is without deleting this then that would be my
preference.

Since I don't know exact issue your seeing, I can't really comment on if
its a good idea to delete this.

If you do decide to delete this logic then I'd say we official do not
support the *old* 2 finger drivers and so I'd delete the Protocol 4
DOUBLETAP and TRIPLETAP logic in wcmUSB.c and  wcmValidateDevice.c as part
of this patch as well.  Touchpad's using old drivers but without this code
become close to un-usable with all the cursor jumping that occurs.

Chris


Signed-off-by: Ping Cheng pi...@wacom.com
 Acked-by: Jason Gerecke killert...@gmail.com
 ---
 v2: only patch 2/4 has code change from Jason's comments. To ease the
 review
 and merge effort, I updated all to v2 with acked-by and reviewed-by tags.
 ---
  src/wcmUSB.c |   34 ++
  1 file changed, 2 insertions(+), 32 deletions(-)

 diff --git a/src/wcmUSB.c b/src/wcmUSB.c
 index e192489..4b5f53b 100644
 --- a/src/wcmUSB.c
 +++ b/src/wcmUSB.c
 @@ -37,7 +37,6 @@ typedef struct {
 Bool wcmPenTouch;
 Bool wcmUseMT;
 int wcmMTChannel;
 -   int wcmPrevChannel;
 int wcmEventCnt;
 struct input_event wcmEvents[MAX_USB_EVENTS];
 int nbuttons;/* total number of buttons */
 @@ -1601,11 +1600,8 @@ static void usbDispatchEvents(InputInfoPtr pInfo)
 return;
 }

 -   /* Protocol 5 devices have some complications related to DUALINPUT
 -* support and can not use below logic to recover from input
 -* event filtering.  Instead, just live with occasional dropped
 -* event.  Since tools are dynamically assigned a channel #, the
 -* structure must be initialized to known starting values
 +   /* Protocol 5 tools are dynamically assigned with channel numbers.
 +* The structure must be initialized to known starting values
  * when first entering proximity to discard invalid data.
  */
 if (common-wcmProtocolLevel == WCM_PROTOCOL_5)
 @@ -1614,32 +1610,6 @@ static void usbDispatchEvents(InputInfoPtr pInfo)
 memset(common-wcmChannel[channel],0,
sizeof(WacomChannel));
 }
 -   else
 -   {
 -   /* Because of linux input filtering, each switch to a new
 -* tool is required to have its initial values match values
 -* of previous tool.
 -*
 -* For normal case, all tools are in channel 0 and so
 -* no issue.  Protocol 4 2FGT devices split between
 -* two channels though and so need to copy data between
 -* channels to prevent loss of events; which could
 -* lead to cursor jumps.
 -*
 -* PAD device is special.  It shares no events
 -* with other channels and is always in proximity.
 -* So it requires no copying of data from other
 -* channels.
 -*/
 -   if (private-wcmPrevChannel != channel 
 -   channel != PAD_CHANNEL 
 -   private-wcmPrevChannel != PAD_CHANNEL)
 -   {
 -   common-wcmChannel[channel].work =
 -
 common-wcmChannel[private-wcmPrevChannel].work;
 -   private-wcmPrevChannel = channel;
 -   }
 -   }

 ds = common-wcmChannel[channel].work;
 dslast = common-wcmChannel[channel].valid.state;
 --
 1.7.10.4



 --
 LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
 Remotely access PCs and mobile devices and provide instant support
 Improve your efficiency, and focus on delivering more value-add services
 Discover what IT Professionals Know. Rescue delivers
 http://p.sf.net/sfu/logmein_12329d2d
 ___
 Linuxwacom-devel mailing list
 Linuxwacom-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what

Re: [Linuxwacom-devel] [PATCH 3/4 v2] Send generic PAD events before other events

[Chris Bagwell]

On Sun, Dec 16, 2012 at 7:17 PM, Ping Cheng pingli...@gmail.com wrote:

 On Sun, Dec 16, 2012 at 1:40 PM, Chris Bagwell ch...@cnpbagwell.comwrote:




 On Thu, Dec 13, 2012 at 2:18 PM, Ping Cheng pingli...@gmail.com wrote:

 If we wait until we finish other verifications, we could miss
 PAD events since they will be filtered out when there are no
 motion events sent simultaneously.



 Signed-off-by: Ping Cheng pingli...@gmail.com
 Acked-by: Jason Gerecke killert...@gmail.com
 ---
  src/wcmUSB.c |   13 +
  1 file changed, 13 insertions(+)

 diff --git a/src/wcmUSB.c b/src/wcmUSB.c
 index 0ea2093..f15a6a2 100644
 --- a/src/wcmUSB.c
 +++ b/src/wcmUSB.c
 @@ -1655,6 +1655,19 @@ static void usbDispatchEvents(InputInfoPtr pInfo)
 {
 usbParseKeyEvent(common, event, channel);
 usbParseBTNEvent(common, event,
 private-wcmBTNChannel);
 +
 +   /* send PAD events now for generic devices.
 Otherwise,
 +* they are filtered out when there are no
 motion events.
 +*/
 +   if ((common-wcmProtocolLevel ==
 WCM_PROTOCOL_GENERIC)
 +   
 (common-wcmChannel[private-wcmBTNChannel].dirty))
 +{
 +   DBG(10, common, Dirty flag set on
 channel %d; 
 +   sending event.\n,
 private-wcmBTNChannel);
 +
 common-wcmChannel[private-wcmBTNChannel].dirty = FALSE;
 +   wcmEvent(common, private-wcmBTNChannel,
 +
  common-wcmChannel[private-wcmBTNChannel].work);
 +   }



 I don't understand this one.  How are they filtered out?  Is
 usbDispatchEvents() returning early or is it some other function?


 It is returned immediarely by the next if statement since both device_type
 and proximity are zero when no touch events.


I see.  Now I can understand why you had patch 1/4 as well.

The intent was that the button channel's ds-device_type and ds-proximity
is fixed and initialized one time up front by usbWcmInitPadState(). That
function was added specifically because its known that no BTN_TOOL_* like
event will kick the code to set up PAD's device_type and proximity for
generic devices.

The code in 1/4  patch was being to agressive and setting these fields to
zero and then confusing all kinds of stuff from there.  If we submit patch
1/4 then can this patch be dropped?  Does it do anything useful once
device_type and proximity stay at good values for PAD?

Chris


 I can tell from the if() that its a Generic device... which one though?


 All generic devices that support PAD the new way in the kernel.



 I suspect the events get ignored because we are not initlizing the ds
 structure correctly.  I'd prefer to get that resolved instead of
 duplicating logic in two places.


 For generic PAD, we can not initialize ds correctly. There is no ds for
 generic PAD. It is ride on one of the touch points, normally the first one.


 Or if we decide this route is best/easiest then I'd prefer if we at least
 move all Button processing earlier and then at the for() loop below we skip
 over button channel always.


 Other PADs do not need this route since they have their own channel (ds).

 Ping

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH 1/4] Remove channel duplication code for generic devices

[Chris Bagwell]

On Thu, Dec 13, 2012 at 9:37 PM, Peter Hutterer peter.hutte...@who-t.netwrote:

 On Wed, Dec 12, 2012 at 11:08:17AM -0800, Ping Cheng wrote:
  On Wed, Dec 12, 2012 at 10:54 AM, Jason Gerecke killert...@gmail.com
 wrote:
 
   It certainly doesn't hurt :) I think my biggest problem is that I never
   really understood exactly when this code was required.
 
 
  I bet you don't want to know ;-). Chris knows this chunk of code way
 better
  than me. It is a long story and it is history already. I'll share it
  offline, with those who are curious...

 no, please share it online so it's archived for future generations.
 this code isn't that old, so if we can't even remember what it was written
 for we really need to document better.

 commit messages are free, we might as well use them properly.

 afaict, this code was there because before the MT protocol we used the
 BTN_TOOL_DOUBLETAP and friends to switch between tools. but because this
 was
 abusing the system a bit, switching to a different tool wouldn't update the
 other coordinates for that tool (the kernel would skip those events if they
 were on the last-sent coordinates for the previous tool), so we had to copy
 that around in the driver.

 except for the pad which is always in proximity and didn't rely on
 multiplexing, so we could skip that.

 does this sound correct?

 Cheers,
Peter


Right, except that tool means fingers in this case.  The old kernel way
is explained in some detail on this page under the Touchpad Overview
section.

https://sourceforge.net/apps/mediawiki/linuxwacom/index.php?title=Kernel_Input_Event_Overview

The concept of that deleted code is that any user land apps need to track
last values sent by kernel that are shared between tools and when switching
tools you need to continue using the last sent values because of event
filtering.  Since we are storing X/Y/Pressure in different channels, when
switching channels the X/Y/Pressure fields need to be copied over at switch
time.

For MT devices, there is not same concept of shared events so the code can
be deleted.

Protocol 5 devices and any Protocol 4 with mice do in fact need similar
logic but we don't have it; as the Protocol 5 deleted comment alludes to.
We are most likely losing data during some tool/finger switch overs for
those devices but since they mostly work in Absolute mode almost no one
notices it because of fast recovery.

FYI: I see now that I documented Synaptics wrong on wiki.The
X/Y/Pressure for syntaptics are really always bound to the FINGER tool and
DOUBLETAP is more an extra tool with no X/Y/Pressure associated directly
with it.  Something closer to this:

 * BTN_TOOL_FINGER
   * BTN_TOUCH
   * ABS_X
   * ABS_Y
   * ABS_PRESSURE
 * BTN_TOOL_DOUBLETAP
 * BTN_LEFT
 * BTN_RIGHT

Chris


 
  Ping
 
  It makes sense that only MT using *TAP events would need it (or
 dual-track,
   but that's protocol 5), so I don't really see any problem given the
 testing
   you've done.
  
  
   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.
  
  
  
   On Wed, Dec 12, 2012 at 10:39 AM, Ping Cheng pingli...@gmail.com
 wrote:
  
   On Wed, Dec 12, 2012 at 9:45 AM, Jason Gerecke killert...@gmail.com
 wrote:
  
   Though I can't quite convince myself that this is safe, I don't see
 any
   problems with it.
  
   Acked-By: Jason Gerecke killert...@gmail.com
  
  
   Will I say it is tested on older and new systems make it easier to
   convince you?
  
   Ping
  
  
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.
  
  
  
   On Thu, Dec 6, 2012 at 4:20 PM, Ping Cheng pingli...@gmail.com
 wrote:
  
   We use true MT protocol for MT devices in kernel now. This code
   was introduced to deal with ABS_TOOL_*TAP events loss issue. It
   is uncessary any more. And its existence makes it hard to support
   generic PAD cleanly.
  
   Signed-off-by: Ping Cheng pi...@wacom.com
   ---
src/wcmUSB.c |   34 ++
1 file changed, 2 insertions(+), 32 deletions(-)
  
   diff --git a/src/wcmUSB.c b/src/wcmUSB.c
   index e192489..4b5f53b 100644
   --- a/src/wcmUSB.c
   +++ b/src/wcmUSB.c
   @@ -37,7 +37,6 @@ typedef struct {
   Bool wcmPenTouch;
   Bool wcmUseMT;
   int wcmMTChannel;
   -   int wcmPrevChannel;
   int wcmEventCnt;
   struct input_event wcmEvents[MAX_USB_EVENTS];
   int nbuttons;/* total number of buttons */
   @@ -1601,11 +1600,8 @@ static void usbDispatchEvents(InputInfoPtr
 pInfo)
   return

Re: [Linuxwacom-devel] [PATCH libwacom] Drop AM_MAINTAINER_MODE

[Chris Bagwell]

On Mon, Oct 15, 2012 at 8:34 PM, Peter Hutterer
peter.hutte...@who-t.net wrote:
 We want libwacom to react to changes in Makefile.am's

 Long writeup:
 http://blogs.gnome.org/desrt/2011/09/08/am_maintainer_mode-is-not-cool/

 Signed-off-by: Peter Hutterer peter.hutte...@who-t.net

For what its worth, for projects that do like to enable maintainer
mode, I prefer they also check in the Makefile.in's because of the
grief that can occur when git is missing them and configure is
ignoring that role.  Since wacom doesn't check them in, I also prefer
deleting this line.

Also, I think projects that distribute an autogen.sh scripts have
their roots in this setting as well.  Its primary feature is a short
cut to force Makefile regeneration when we've gone out of our way to
disable that automatice feature.  Its an option to either delete that
script now or remove the configure part.  Hopefully, people that muck
with configure.ac scripts already know you need to run autoreconf
after modifying it and the Makefile will now have working rules to
rerun configure after modifying Makefile.am.

Reviewed-by: Chris Bagwell ch...@cnpbagwell.com

 ---
  configure.ac | 1 -
  1 file changed, 1 deletion(-)

 diff --git a/configure.ac b/configure.ac
 index 432f0e7..e510e2f 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -5,7 +5,6 @@ AC_CONFIG_HEADERS([config.h])

  # Initialize Automake
  AM_INIT_AUTOMAKE([foreign dist-bzip2 no-dist-gzip check-news])
 -AM_MAINTAINER_MODE

  # Enable silent build when available (Automake 1.11)
  m4_ifdef([AM_SILENT_RULES],[AM_SILENT_RULES([yes])])
 --
 1.7.11.4


 --
 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

Re: [Linuxwacom-devel] [RFC PATCH 9/9]: Always allow single finger gestures

[Chris Bagwell]

On Sat, Sep 29, 2012 at 6:58 PM, Jason Gerecke killert...@gmail.com 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 ch...@cnpbagwell.com


  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 \fIGesture\fP \fIbool\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 \fIZoomDistance\fP \fInumber\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

--
Don't let slow site performance ruin your business. Deploy New Relic APM

Re: [Linuxwacom-devel] [PATCH 0/9] Multitouch support patches

[Chris Bagwell]

On Sat, Sep 29, 2012 at 6:58 PM, Jason Gerecke killert...@gmail.com 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 ch...@cnpbagwell.com

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] [PATCH 0/9] Multitouch support patches

[Chris Bagwell]

On Sat, Sep 29, 2012 at 6:58 PM, Jason Gerecke killert...@gmail.com 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).


Glad to see some momentum here.  I've done the following with your
patches so far:

 * Applied your patches to xf86-input-wacom and running under Fedora 18 Alpha.
 * Found the Fedora 17 Touchegg SRPMs you mentioned and
recompiledinstalled on Fedora 18 Alpha.

Here is what I noticed so far:

 * Quick testing with updated xf86-input-wacom seemed to act same with
default gestures enabled.
 * When I disabled gestures, I didn't notice anything special in
out-of-box Fedora 18 Alpha.  Looks like Mutter still doesn't have any
gesture support and I couldn't find any apps that have built in XI2.2
gesture support.
 * Launching touchegg from terminal looks like it dumps lots of useful
info to the screen.  With default config file, I could get 2 finger
scrolling and 3 finger window move to kick in but not consistently.
Something feels a little off but I have no baseline to compare
behaviour to so I've no idea how well I should expect it to be
working.

I'll move on to reviewing patches and debugging any issues next.

Chris

--
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
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH] Input: wacom - Mark Intuos5 pad as in-prox when touching buttons

[Chris Bagwell]

On Fri, Sep 14, 2012 at 6:30 PM, Jason Gerecke killert...@gmail.com wrote:
 If the ExpressKeys on the Intuos5 are touched, they currently result
 an out-of-prox packet being sent even if the pad is already out of
 prox. This can cause some confusion in the X driver. To restore the
 expected semantics, we make being touched a sufficient condition to
 signal proximity.

Seems like easiest solution to prevent invalid event sequencies.

Reviewed-by: Chris Bagwell ch...@cnpbagwell.com


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

 Reported-by: Timo Aaltonen tjaal...@ubuntu.com
 Signed-off-by: Jason Gerecke killert...@gmail.com
 ---
  drivers/input/tablet/wacom_wac.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/input/tablet/wacom_wac.c 
 b/drivers/input/tablet/wacom_wac.c
 index 532d067..9317109 100644
 --- a/drivers/input/tablet/wacom_wac.c
 +++ b/drivers/input/tablet/wacom_wac.c
 @@ -606,7 +606,7 @@ static int wacom_intuos_irq(struct wacom_wac *wacom)
 input_report_abs(input, ABS_WHEEL, 0);
 }

 -   if (data[2] | (data[3]  0x01) | data[4]) {
 +   if (data[2] | (data[3]  0x01) | data[4] | data[5]) {
 input_report_key(input, wacom-tool[1], 1);
 input_report_abs(input, ABS_MISC, 
 PAD_DEVICE_ID);
 } else {
 --
 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] Pre-allocate the tap timer

[Chris Bagwell]

On Wed, Aug 22, 2012 at 8:06 PM, Peter Hutterer
peter.hutte...@who-t.net wrote:
 wcmSingleFingerTap() is called during SIGIO, calling TimerSet(NULL, ...)
 will malloc inside the signal handler and hang the box.

 Signed-off-by: Peter Hutterer peter.hutte...@who-t.net

I haven't seen the lockup but makes sense.

Acked-by: Chris Bagwell ch...@cnpbagwell.com

 ---
  src/wcmConfig.c  | 2 ++
  src/wcmTouchFilter.c | 2 +-
  src/xf86WacomDefs.h  | 1 +
  3 files changed, 4 insertions(+), 1 deletion(-)

 diff --git a/src/wcmConfig.c b/src/wcmConfig.c
 index 157d9d3..24ec85b 100644
 --- a/src/wcmConfig.c
 +++ b/src/wcmConfig.c
 @@ -102,6 +102,7 @@ static int wcmAllocate(InputInfoPtr pInfo)

 /* timers */
 priv-serial_timer = TimerSet(NULL, 0, 0, NULL, NULL);
 +   priv-tap_timer = TimerSet(NULL, 0, 0, NULL, NULL);

 return 1;

 @@ -125,6 +126,7 @@ static void wcmFree(InputInfoPtr pInfo)
 return;

 TimerFree(priv-serial_timer);
 +   TimerFree(priv-tap_timer);
 free(priv-tool);
 wcmFreeCommon(priv-common);
 free(priv);
 diff --git a/src/wcmTouchFilter.c b/src/wcmTouchFilter.c
 index d25608b..bf0ecec 100644
 --- a/src/wcmTouchFilter.c
 +++ b/src/wcmTouchFilter.c
 @@ -201,7 +201,7 @@ static void wcmSingleFingerTap(WacomDevicePtr priv)
 common-wcmGestureMode = GESTURE_PREDRAG_MODE;

 /* Delay to detect possible drag operation */
 -   TimerSet(NULL, 0, 
 common-wcmGestureParameters.wcmTapTime, wcmSingleFingerTapTimer, priv);
 +   TimerSet(priv-tap_timer, 0, 
 common-wcmGestureParameters.wcmTapTime, wcmSingleFingerTapTimer, priv);
 }
 }
  }
 diff --git a/src/xf86WacomDefs.h b/src/xf86WacomDefs.h
 index 45970dc..38a0411 100644
 --- a/src/xf86WacomDefs.h
 +++ b/src/xf86WacomDefs.h
 @@ -304,6 +304,7 @@ struct _WacomDeviceRec
 int isParent;   /* set to 1 if the device is not 
 auto-hotplugged */

 OsTimerPtr serial_timer; /* timer used for serial number property 
 update */
 +   OsTimerPtr tap_timer;   /* timer used for tap timing */
  };

  
 /**
 --
 1.7.11.2


 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Linuxwacom-devel mailing list
 Linuxwacom-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH 3/3] release.sh: support other modules (i.e. libwacom and input-wacom)

[Chris Bagwell]

On Mon, Jul 9, 2012 at 7:07 PM, Peter Hutterer peter.hutte...@who-t.net wrote:
 Add a --module switch to the release script so we can use the same script
 for all three linuxwacom projects.

 Signed-off-by: Peter Hutterer peter.hutte...@who-t.net

Oh, I guess I should have read patches in order they were sent. :-)
Never mind on my other comment.

For the series:

Reviewed-by: Chris Bagwell ch...@cnpbagwell.com

Chris

 ---
  release.sh |   24 ++--
  1 file changed, 22 insertions(+), 2 deletions(-)

 diff --git a/release.sh b/release.sh
 index 2d6f1d4..4a403a7 100755
 --- a/release.sh
 +++ b/release.sh
 @@ -10,8 +10,6 @@ discuss_list=linuxwacom-disc...@lists.sourceforge.net
  module=xf86-input-wacom
  user=${USER}@
  host=shell.sourceforge.net
 -srv_path=/home/frs/project/l/li/linuxwacom/$module
 -webpath=sourceforge.net/projects/linuxwacom/files/$module
  remote=origin

  usage()
 @@ -25,6 +23,8 @@ Options:
--helpthis help message
--ignore-local-changesdon't abort on uncommitted local changes
--remote  git remote where the change should be pushed (default 
 origin)
 +  --module module release the given module. Default: xf86-input-wacom
 +Supported modules: xf86-input-wacom, libwacom
  HELP
  }

 @@ -93,6 +93,11 @@ while [ $# != 0 ]; do
  remote=$1
  shift
  ;;
 +--module)
 +shift
 +module=$1
 +shift
 +;;
  --*)
  echo error: unknown option
  usage
 @@ -111,12 +116,25 @@ while [ $# != 0 ]; do
  esac
  done

 +case $module in
 +libwacom)
 +;;
 +xf86-input-wacom)
 +;;
 +input-wacom)
 +;;
 +*)
 +echo error: unknown module '$module'
 +exit 1
 +esac
 +
  if [ -z $tag_previous ] || [ -z $tag_current ]; then
  echo error: missing previous or current tag
  usage
  exit 1
  fi

 +
  # Check for uncommitted/queued changes.
  if [ x$ignorechanges != x1 ]; then
  set +e
 @@ -172,6 +190,8 @@ fi
  modulever=$module-$version
  tarbz2=$modulever.tar.bz2
  announce=$tarball_dir/$modulever.announce
 +srv_path=/home/frs/project/l/li/linuxwacom/$module
 +webpath=sourceforge.net/projects/linuxwacom/files/$module

  echo checking parameters
  if ! [ -f $tarball_dir/$tarbz2 ]; then
 --
 1.7.10.4


 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Linuxwacom-devel mailing list
 Linuxwacom-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH libwacom 1/3] data: define button positions for Bamboos

[Chris Bagwell]

On Wed, Jun 6, 2012 at 11:30 AM, Jason Gerecke killert...@gmail.com wrote:
 On Wed, Jun 6, 2012 at 6:04 AM, Bastien Nocera had...@hadess.net wrote:
 On Tue, 2012-05-29 at 15:28 +1000, Peter Hutterer wrote:
 On Tue, May 29, 2012 at 02:25:11PM +1000, Peter Hutterer wrote:
  Signed-off-by: Peter Hutterer peter.hutte...@who-t.net

 yikes. after running a few more tests I realised that this isn't actually
 enough. the bamboos define buttons 1, 3, 8 and 9 and we cannot currently
 handle non-continuous button ranges, neither in libwacom nor the gnome
 stack. So button 9 is unknown, as we expect buttons 1, 2, 3 and 8.

 So the below patch only solves the problem partially.

 as for solutions: I think claiming the bamboo has 5 buttons would be a good
 enough hack for now until we add non-continuous button range support.
 Opinions?

 Make the driver fix it?

 Can you expand on that a little more?

 The long-term solution that springs first to my mind (because its been
 *on* my mind for months) would be to change how the Wacom Button
 Actions property is indexed. Instead of having it be indexed by the
 X11 button number I think it should be indexed by the kernel button
 number (i.e. identically to libwacom). The problem with my grand idea
 is that it breaks anything which reads/writes the properties directly.
 Not breaking users existing configs is pretty high on the priority
 list, so this plan is a non-starter without hashing out some kind of
 migration plan to keep the GNOME and KDE panels working.

 If you've got an idea of your own though, I'm all ears.


Kernel side for Bamboo driver seems reasonable on this.  Its declaring
a left button, right button, a forward button, and a back button.
Other similar tables are reporting buttons 0,1,2,3 or 1,2,3,4
(especially if they do not have touch support).

I think long term all 3 of those choices are going to be valid kernel
choices.  Also, I think its reasonable X input driver behavior that in
all 3 cases it has 2 of the buttons as left and right click by default
and 2 are back/forward by default.  I'd be scratching my head if by
default 2 buttons were for mouse scroll.  So I don't think I'd change
the default mapping their either.

So to me the really on reasonable choice left is to address the
indexing issue you point out.  I personally think we are safe to do
this change at this time.  We have been so buggy in this area for
xsetwacom button maps, X properties button mappings, and xinput
set-button-map that I bet if we review every xf86-input-wacom release
(not git) for last 3 years, every single release had a different
behavior for button mappings in xsetwacom vs. properties vs xinput.

Chris

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH 01/14] Fix warning: Remove superflous casts in getScrollDelta

[Chris Bagwell]

On Fri, May 25, 2012 at 2:49 PM, Jason Gerecke killert...@gmail.com wrote:
 ../src/xf86Wacom.c: In function 'wcmEventAutoDevProbe':
 ../src/xf86Wacom.c:527:5: warning: return discards 'const' qualifier from 
 pointer target type [enabled by default]

I'm thinking you copied the wrong warning here?

In other patches, I do not know 100% that -NULL is OK but seems reasonable.

For all in series:

Reviewed-by: Chris Bagwell ch...@cnpbagwell.com


 Signed-off-by: Jason Gerecke killert...@gmail.com
 ---
  src/wcmCommon.c |    6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

 diff --git a/src/wcmCommon.c b/src/wcmCommon.c
 index 7199105..edbcd68 100644
 --- a/src/wcmCommon.c
 +++ b/src/wcmCommon.c
 @@ -330,9 +330,9 @@ static int getScrollDelta(int current, int old, int wrap, 
 int flags)

        if (flags  AXIS_BITWISE)
        {
 -               current = (int)log2((current  1) | 0x01);
 -               old = (int)log2((old  1) | 0x01);
 -               wrap = (int)log2((wrap  1) | 0x01);
 +               current = log2((current  1) | 0x01);
 +               old = log2((old  1) | 0x01);
 +               wrap = log2((wrap  1) | 0x01);
        }

        delta = current - old;
 --
 1.7.10.2


 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Linuxwacom-devel mailing list
 Linuxwacom-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH 1/1] Add support for the DTI-520

[Chris Bagwell]

On Thu, May 17, 2012 at 6:38 PM, Adam Nielsen a.niel...@shikadi.net wrote:
 just wondering if the DTI-520 gives you serial numbers for the styli or if
 this device uses generic serials.

 DTI-520 is a protocol 4 (V4) device. It does not support serial number
 and tool IDs.

 What does protocol 4 refer to?  Do you know why the USB communication
 protocol used on this tablet is completely different to all other Wacom 
 tablets?

This page will give you the scoop on protocol 4.

http://sourceforge.net/apps/mediawiki/linuxwacom/index.php?title=Wacom_Protocol_Overview

Chris

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] Waltop class?

[Chris Bagwell]

On Tue, May 1, 2012 at 7:56 AM, Nikolai Kondrashov spbn...@gmail.comwrote:

 On 05/01/2012 03:44 PM, Nikolai Kondrashov wrote:
  I would very much like to have a single class for generic tablets
 instead.
  They're all very similar and the evdev interface is capable of providing
 all
  the required information about them. It does that for all the tablets
  handled by hid-waltop, hid-uclogic and hid-kye drivers, at least.
 
  I've been attempting to implement this maybe twice in the past, but
 didn't
  have time or dedication to finish it.

 Sorry, I confused libwacom classes with wcmUSB.c protocols. I was talking
 about the latter here. However, it probably applies to the former as well.


Here are my two cents on the topic.  If I was designing Class field in
libwacom from scratch, I'm not sure if I'd bother because it at best an
ackward summary of the individual [Features].  If I were asked to convert
today's Classes to generic names, it would be something like this:

Tablet PC - ISDV4's and Serial
Monitor with Digitizer - Cintiq's and DTx's
Simple Tablet (no rings or modes and no tool serial #) - Bamboo's
Simple Tablet + Mouse (no rings or modes and no tool serial # even though 2
tools)- Graphires
Complex Tablet with rings and/or Mode settings to change button or ring
meanings. - Intuos's

WCLASS_ISDV4 can be used as generic name for Tablet PC's.  WCLASS_CINTIQ
can be used as generic name for Monitor with Digitizer (see issue below
though).  WCLASS_BAMBOO and WCLASS_GRAPHIRE are both Simple Tablets with
the later having a MOUSE.  I'm not really sure why we have 3 versions of
WCLASS_INTUOS but they are all the Complex Tablets.

Technically, there are Simple Monitor's (the DTx's) and Complex
Monitor's (the Cintiq's are as complex as Intuos).  So our current classes
are unbalanced.

Anyways, we can either re-use those classes in a generic sense or add
generic versions.  If adding generic versions, I'm not if sure if 5 or more
are even needing.  In [Features] section, BuiltIn tells differences between
Tablet PC/Monitor vs Tablets and NumStrips/Ring/etc tell Simple vs. Complex.

Chris
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] Bamboo wireless support on Ubuntu 12.04

[Chris Bagwell]

What kernel version does 12.04 use?

The wireless support has been queued up for kernel 3.4 so once its released
and put in 12.04, it will work.

I hope to submit to input-wacom soon so people can follow instructions on
wacom wiki to get working.

Chris

On Wed, Apr 25, 2012 at 1:21 AM, Thierry Munoz thierry.mu...@free.frwrote:

 Hi,
 I have tested the driver here
 (https://sourceforge.net/mailarchive/message.php?msg_id=28634134) on
 Ubuntu Precise Pangolin 12.04 and it doesn't work. This driver was
 working under Ubuntu 11.10 (version from I updated).
 My tablet is a CTH-470K that's working when it's wired on USB.
 Regards,

 Thierry


 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Linuxwacom-devel mailing list
 Linuxwacom-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH] Fix off-by-one error in xsetwacom's button handling

[Chris Bagwell]

Seems reasonable a zero based offset should check = nitems value and
aligns with similar check in get_actions().

Reviewed-by: Chris Bagwell ch...@cnpbagwell.com

On Tue, Apr 3, 2012 at 5:00 PM, Jason Gerecke killert...@gmail.com wrote:


 Signed-off-by: Jason Gerecke killert...@gmail.com
 ---
  tools/xsetwacom.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
 index 7cf0d05..28332d1 100644
 --- a/tools/xsetwacom.c
 +++ b/tools/xsetwacom.c
 @@ -1244,7 +1244,7 @@ static void special_map_property(Display *dpy,
 XDevice *dev, Atom btnact_prop, i
AnyPropertyType, type, format,
 btnact_nitems,
bytes_after, (unsigned
 char**)btnact_data);

 -   if (offset  btnact_nitems)
 +   if (offset = btnact_nitems)
{
fprintf(stderr, Invalid offset into %s property.\n,
 XGetAtomName(dpy, btnact_prop));
goto out;
 --
 1.7.9.5



 --
 Better than sec? Nothing is better than sec when it comes to
 monitoring Big Data applications. Try Boundary one-second
 resolution app monitoring today. Free.
 http://p.sf.net/sfu/Boundary-dev2dev
 ___
 Linuxwacom-devel mailing list
 Linuxwacom-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH 1/1] Use kernel-reported tilt range and resolution

[Chris Bagwell]

On Thu, Mar 29, 2012 at 2:22 AM, Nikolai Kondrashov spbn...@gmail.com wrote:
 Hi Chris,


 On 03/23/2012 07:20 PM, Nikolai Kondrashov wrote:

 On 03/23/2012 07:00 PM, Chris Bagwell wrote:

 On Thu, Mar 22, 2012 at 2:37 PM, Nikolai Kondrashovspbn...@gmail.com
 wrote:

 + /* Center the reported range on zero */
 + /* FIXME remove once kernel is fixed */
 + common-wcmTiltXOff = - (absinfo.minimum + absinfo.maximum) / 2;


 Why is this a FIXME? It seems reasonable to center to zero here. For
 example, there is no intention to fix Wacom kernel drivers, are
 there?


 Well, I intended to fix them, actually. The thing is, the existing range
 wacom drivers use is not straightforward and contradicts HID
 specification.

 I was hoping to make a patch for the kernel drivers, so, after a while (at
 your discretion), this centering could be dropped.


 Do you still object to the FIXME and fixing the kernel driver?


Opps. I meant to reply but didn't.

I've no objection to the code itself but I would prefer if the FIXME
was reduced to a TODO or left as only a comment on how current kernels
are behaving.

If you update the kernels great but its not something that *has* to be
fixed on xf86-input-wacom side and I'd hate to see the FIXME's there
for ever in code thats working fine.

Chris

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH input-wacom 1/2] backport: add support for Cintiq 24HD

[Chris Bagwell]

On Wed, Mar 28, 2012 at 12:31 PM, Ping Cheng pingli...@gmail.com wrote:
 On Wed, Mar 28, 2012 at 9:29 AM, Jason Gerecke killert...@gmail.com wrote:
 Based on upstream commit 803296b678a43005e3bc0aaa1951d211bd76a054

 Signed-off-by: Jason Gerecke killert...@gmail.com

 Acked-by: Ping Cheng pi...@wacom.com for the set.

 Ping

Are you going to commit patches yourself, Jason?

I had hoped for 2.6.36 that I'd copy latest upstream source into that
directory at some point instead of porting the 3 or so missing
features... but I'm getting a little worried that we will need a 3.3
or 3.4 branch soon.  If I compile the latest upstream version against
my 3.2 kernel headers then it results in a non-working driver.  So we
may need to port each feature like you've done for 2.6.36 after all.

Chris

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH input-wacom 1/2] backport: add support for Cintiq 24HD

[Chris Bagwell]

On Thu, Mar 29, 2012 at 10:36 AM, Jason Gerecke killert...@gmail.com wrote:
 On Thu, Mar 29, 2012 at 6:54 AM, Chris Bagwell ch...@cnpbagwell.com wrote:
 On Wed, Mar 28, 2012 at 12:31 PM, Ping Cheng pingli...@gmail.com wrote:
 On Wed, Mar 28, 2012 at 9:29 AM, Jason Gerecke killert...@gmail.com wrote:
 Based on upstream commit 803296b678a43005e3bc0aaa1951d211bd76a054

 Signed-off-by: Jason Gerecke killert...@gmail.com

 Acked-by: Ping Cheng pi...@wacom.com for the set.

 Ping

 Are you going to commit patches yourself, Jason?

 Yeah, just haven't gotten around to it yet.

 I had hoped for 2.6.36 that I'd copy latest upstream source into that
 directory at some point instead of porting the 3 or so missing
 features... but I'm getting a little worried that we will need a 3.3
 or 3.4 branch soon.  If I compile the latest upstream version against
 my 3.2 kernel headers then it results in a non-working driver.  So we
 may need to port each feature like you've done for 2.6.36 after all.

 Chris

 What's the problem you're having with the 3.2 headers? I just compiled
 input-wacom with my I5 backports and your upstream wireless patches
 (tweaked as necessary) and don't seem to be running into any trouble
 with the resulting driver working with the Arch Linux 3.2.11-1 kernel.

Good to know its working OK for you.  I'm on Fedora using one of their
3.2 kernels.  They are pretty aggressive at patching the kernels and
its not uncommon for internal structures to be closer to future
releases.

When compiling the wacom files from dtor's for-linus branch but
against current kernels header files I get a new warning:

linux/drivers/input/tablet/wacom_sys.c:1166:1: warning: data
definition has no type or storage class [enabled by default]

and the driver loads OK but doesn't do anything.


 I've recently been looking at how the versions are diverging, and
 there's a couple things that need to be addressed. Some are trivial,
 while others may need testing. Most of the differences though looks to
 be pretty easy to merge back to 2.6.30, or possibly even 2.6.16 (I'm
 not familiar enough with the legacy linuxwacom code to be sure of that
 statement...). The hard part will be testing to ensure everything
 works properly.

I see I was a little confused in my statement.  I meant to say I plan
to copy latest upstream to 2.6.38; not 2.6.36.  I guess that anything
for 2.6.36 still needs hand porting.

I did start a Bamboo 3rd gen backport to 2.6.36 but its stalled out at
the moment.

Chris


 If I can get some time, I'd like to work out what needs to be done to
 get everything in sync again. Backporting I5 took longer than expected
 because of all the small bumps in the merge process

 Jason

 ---
 Day xee-nee-svsh duu-'ushtlh-ts'it;
 nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it.
 Huu-chan xuu naa~-gha.

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH 1/1] Use kernel-reported tilt range and resolution

[Chris Bagwell]

 */
 +       if (ISBITSET(abs, ABS_TILT_X) 
 +                       !ioctl(pInfo-fd, EVIOCGABS(ABS_TILT_X), absinfo))
 +       {
 +               /* Center the reported range on zero */
 +               /* FIXME remove once kernel is fixed */
 +               common-wcmTiltXOff = - (absinfo.minimum + absinfo.maximum) / 
 2;

Why is this a FIXME?  It seems reasonable to center to zero here.  For
example, there is no intention to fix Wacom kernel drivers, are
there?  If their driver is updated to send min/max (or are they
already?), then this logic is still needed for them to continue
working as expected.

I'd resolve first (if anything to resolve) and delete FIXME before submitting.

I've no other comments other than I hope a Intuos user can test patch first.

Chris

 +#if LINUX_VERSION_CODE  KERNEL_VERSION(2,6,30)
 +               /* If resolution is specified */
 +               if (absinfo.resolution  0)
 +               {
 +                       int max_angle = round(MAX_TILT_ANGLE *
 +                                             absinfo.resolution);
 +
 +                       /*
 +                        * Clamp/extend the kernel range to the range
 +                        * expected by applications
 +                        */
 +                       common-wcmTiltXMin = -max_angle;
 +                       common-wcmTiltXMax = max_angle;
 +               }
 +               else
 +#endif
 +               {
 +                       /*
 +                        * Assume the angles reported by the kernel cover
 +                        * exactly the range expected by applications
 +                        */
 +                       common-wcmTiltXMin = absinfo.minimum +
 +                                             common-wcmTiltXOff;
 +                       common-wcmTiltXMax = absinfo.maximum +
 +                                             common-wcmTiltXOff;
 +               }
 +       }
 +
 +       /* Y tilt range */
 +       if (ISBITSET(abs, ABS_TILT_Y) 
 +                       !ioctl(pInfo-fd, EVIOCGABS(ABS_TILT_Y), absinfo))
 +       {
 +               /* Center the reported range on zero */
 +               /* FIXME remove once kernel is fixed */
 +               common-wcmTiltYOff = - (absinfo.minimum + absinfo.maximum) / 
 2;
 +#if LINUX_VERSION_CODE  KERNEL_VERSION(2,6,30)
 +               /* If resolution is specified */
 +               if (absinfo.resolution  0)
 +               {
 +                       int max_angle = round(MAX_TILT_ANGLE *
 +                                             absinfo.resolution);
 +
 +                       /*
 +                        * Clamp/extend the kernel range to the range
 +                        * expected by applications
 +                        */
 +                       common-wcmTiltYMin = -max_angle;
 +                       common-wcmTiltYMax = max_angle;
 +               }
 +               else
 +#endif
 +               {
 +                       /*
 +                        * Assume the angles reported by the kernel cover
 +                        * exactly the range expected by applications
 +                        */
 +                       common-wcmTiltYMin = absinfo.minimum +
 +                                             common-wcmTiltYOff;
 +                       common-wcmTiltYMax = absinfo.maximum +
 +                                             common-wcmTiltYOff;
 +               }
 +       }
 +
        /* max z cannot be configured */
        if (ISBITSET(abs, ABS_PRESSURE) 
                        !ioctl(pInfo-fd, EVIOCGABS(ABS_PRESSURE), absinfo))
 @@ -1032,10 +1102,10 @@ static int usbParseAbsEvent(WacomCommonPtr common,
                        ds-rotation = event-value;
                        break;
                case ABS_TILT_X:
 -                       ds-tiltx = event-value - common-wcmMaxtiltX/2;
 +                       ds-tiltx = event-value + common-wcmTiltXOff;
                        break;
                case ABS_TILT_Y:
 -                       ds-tilty = event-value - common-wcmMaxtiltY/2;
 +                       ds-tilty = event-value + common-wcmTiltYOff;
                        break;
                case ABS_PRESSURE:
                        ds-pressure = event-value;
 diff --git a/src/xf86Wacom.c b/src/xf86Wacom.c
 index b04e06d..50c58d9 100644
 --- a/src/xf86Wacom.c
 +++ b/src/xf86Wacom.c
 @@ -240,8 +240,8 @@ wcmInitAxes(DeviceIntPtr pWcm)
        } else
        {
                        label = XIGetKnownProperty(AXIS_LABEL_PROP_ABS_TILT_X),
 -                       min = -64;
 -                       max = 63;
 +                       min = common-wcmTiltXMin;
 +                       max = common-wcmTiltXMax;
                        min_res = max_res = res = 1;
                        mode = Absolute;
        }
 @@ -277,8 +277,8 @@ wcmInitAxes(DeviceIntPtr pWcm)
        } else
        {
                label = XIGetKnownProperty(AXIS_LABEL_PROP_ABS_TILT_Y);
 -               min = -64

Re: [Linuxwacom-devel] [PATCH 3/3] HID: wacom: Add battery/ac reporting for Intuos4 WL

[Chris Bagwell]

Reviewed-by: Chris Bagwell ch...@cnpbagwell.com

On Mon, Mar 19, 2012 at 10:16 AM, Przemo Firszt prz...@firszt.eu wrote:
 This patch adds battery/ac reporting for Intuos4 WL. It uses existing
 sysfs code, but the device reports battery capacity in more fine-grained way,
 so there has to be a separate lookup table (called batcap_i4).

 Signed-off-by: Przemo Firszt prz...@firszt.eu
 ---
  drivers/hid/hid-wacom.c |   10 ++
  1 files changed, 10 insertions(+), 0 deletions(-)

 diff --git a/drivers/hid/hid-wacom.c b/drivers/hid/hid-wacom.c
 index 9c15494..43a96d1 100644
 --- a/drivers/hid/hid-wacom.c
 +++ b/drivers/hid/hid-wacom.c
 @@ -51,6 +51,8 @@ struct wacom_data {
  /*percent of battery capacity for Graphire
   8th value means AC online and show 100% capacity */
  static unsigned short batcap_gr[8] = { 1, 15, 25, 35, 50, 70, 100, 100 };
 +/*percent of battery capacity for Intuos4 WL, AC has a separate bit*/
 +static unsigned short batcap_i4[8] = { 1, 15, 30, 45, 60, 70, 85, 100 };

  static enum power_supply_property wacom_battery_props[] = {
        POWER_SUPPLY_PROP_PRESENT,
 @@ -449,6 +451,7 @@ static int wacom_raw_event(struct hid_device *hdev, 
 struct hid_report *report,
        struct input_dev *input;
        unsigned char *data = (unsigned char *) raw_data;
        int i;
 +       __u8 power_raw;

        if (!(hdev-claimed  HID_CLAIMED_INPUT))
                return 0;
 @@ -476,6 +479,13 @@ static int wacom_raw_event(struct hid_device *hdev, 
 struct hid_report *report,
                        wacom_i4_parse_report(hdev, wdata, input, data + i);
                        i += 10;
                        wacom_i4_parse_report(hdev, wdata, input, data + i);
 +                       power_raw = data[i+10];
 +                       if (power_raw != wdata-power_raw) {
 +                               wdata-power_raw = power_raw;
 +                               wdata-battery_capacity = batcap_i4[power_raw 
  0x07];
 +                               wdata-ps_connected = power_raw  0x08;
 +                       }
 +
                        break;
                default:
                        hid_err(hdev, Unknown report: %d,%d size:%d\n,
 --
 1.7.6.4


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH 1/3] HID: wacom: Remove CONFIG_HID_WACOM_POWER_SUPPLY option

[Chris Bagwell]

On Mon, Mar 19, 2012 at 10:16 AM, Przemo Firszt prz...@firszt.eu wrote:
 This option was ment as a safety mechanism in case the system treats the wacom
 tablet battery as the main power supply. It's no longer required as now we can
 distinguish between system power supply and device power supply.

 Signed-off-by: Przemo Firszt prz...@firszt.eu
 ---
  drivers/hid/Kconfig     |    8 
  drivers/hid/hid-wacom.c |   14 --
  2 files changed, 0 insertions(+), 22 deletions(-)

 diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
 index a421abd..d6ed4ec 100644
 --- a/drivers/hid/Kconfig
 +++ b/drivers/hid/Kconfig
 @@ -623,14 +623,6 @@ config HID_WACOM
        ---help---
        Support for Wacom Graphire Bluetooth tablet.

 -config HID_WACOM_POWER_SUPPLY
 -       bool Wacom Bluetooth devices power supply status support
 -       depends on HID_WACOM
 -       select POWER_SUPPLY

These depends and select lines need to move up to HID_WACOM.  Other than that:

Reviewed-by: Chris Bagwell ch...@cnpbagwell.com

 -       ---help---
 -         Say Y here if you want to enable power supply status monitoring for
 -         Wacom Bluetooth devices.
 -
  config HID_WIIMOTE
        tristate Nintendo Wii Remote support
        depends on BT_HIDP
 diff --git a/drivers/hid/hid-wacom.c b/drivers/hid/hid-wacom.c
 index 067e296..09d102c 100644
 --- a/drivers/hid/hid-wacom.c
 +++ b/drivers/hid/hid-wacom.c
 @@ -41,14 +41,11 @@ struct wacom_data {
        __u32 id;
        __u32 serial;
        unsigned char high_speed;
 -#ifdef CONFIG_HID_WACOM_POWER_SUPPLY
        int battery_capacity;
        struct power_supply battery;
        struct power_supply ac;
 -#endif
  };

 -#ifdef CONFIG_HID_WACOM_POWER_SUPPLY
  /*percent of battery capacity, 0 means AC online*/
  static unsigned short batcap[8] = { 1, 15, 25, 35, 50, 70, 100, 0 };

 @@ -120,7 +117,6 @@ static int wacom_ac_get_property(struct power_supply *psy,
        }
        return ret;
  }
 -#endif

  static void wacom_set_features(struct hid_device *hdev)
  {
 @@ -310,12 +306,10 @@ static int wacom_gr_parse_report(struct hid_device 
 *hdev,
                input_sync(input);
        }

 -#ifdef CONFIG_HID_WACOM_POWER_SUPPLY
        /* Store current battery capacity */
        rw = (data[7]  2  0x07);
        if (rw != wdata-battery_capacity)
                wdata-battery_capacity = rw;
 -#endif
        return 1;
  }

 @@ -596,7 +590,6 @@ static int wacom_probe(struct hid_device *hdev,
                break;
        }

 -#ifdef CONFIG_HID_WACOM_POWER_SUPPLY
        wdata-battery.properties = wacom_battery_props;
        wdata-battery.num_properties = ARRAY_SIZE(wacom_battery_props);
        wdata-battery.get_property = wacom_battery_get_property;
 @@ -629,16 +622,13 @@ static int wacom_probe(struct hid_device *hdev,
        }

        power_supply_powers(wdata-ac, hdev-dev);
 -#endif
        return 0;

 -#ifdef CONFIG_HID_WACOM_POWER_SUPPLY
  err_ac:
        power_supply_unregister(wdata-battery);
  err_battery:
        device_remove_file(hdev-dev, dev_attr_speed);
        hid_hw_stop(hdev);
 -#endif
  err_free:
        kfree(wdata);
        return ret;
 @@ -646,16 +636,12 @@ err_free:

  static void wacom_remove(struct hid_device *hdev)
  {
 -#ifdef CONFIG_HID_WACOM_POWER_SUPPLY
        struct wacom_data *wdata = hid_get_drvdata(hdev);
 -#endif
        device_remove_file(hdev-dev, dev_attr_speed);
        hid_hw_stop(hdev);

 -#ifdef CONFIG_HID_WACOM_POWER_SUPPLY
        power_supply_unregister(wdata-battery);
        power_supply_unregister(wdata-ac);
 -#endif
        kfree(hid_get_drvdata(hdev));
  }

 --
 1.7.6.4


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH 2/2] HID: wacom: Add battery/ac reporting for Intuos4 WL

[Chris Bagwell]

On Sun, Mar 18, 2012 at 11:24 AM, Przemo Firszt prz...@firszt.eu wrote:
 This patch adds battery/ac reporting for Intuos4 WL. It uses existing
 sysfs code, but the device reports battery capacity in more fine-grained way,
 so there has to be a separate lookup table (called batcap_i4).

 Signed-off-by: Przemo Firszt prz...@firszt.eu
 ---
  drivers/hid/hid-wacom.c |   12 
  1 files changed, 12 insertions(+), 0 deletions(-)

 diff --git a/drivers/hid/hid-wacom.c b/drivers/hid/hid-wacom.c
 index 516b468..708b909 100644
 --- a/drivers/hid/hid-wacom.c
 +++ b/drivers/hid/hid-wacom.c
 @@ -53,6 +53,8 @@ struct wacom_data {
  #ifdef CONFIG_HID_WACOM_POWER_SUPPLY
  /*percent of battery capacity for Graphire, 0 means AC online*/
  static unsigned short batcap_gr[8] = { 1, 15, 25, 35, 50, 70, 100, 0 };
 +/*percent of battery capacity for Intuos4 WL, AC has a separate bit*/
 +static unsigned short batcap_i4[8] = { 1, 15, 30, 45, 60, 70, 85, 100 };

  static enum power_supply_property wacom_battery_props[] = {
        POWER_SUPPLY_PROP_PRESENT,
 @@ -457,6 +459,8 @@ static int wacom_raw_event(struct hid_device *hdev, 
 struct hid_report *report,
        struct input_dev *input;
        unsigned char *data = (unsigned char *) raw_data;
        int i;
 +       __u8 battery;
 +       __u8 ps_connected;

        if (!(hdev-claimed  HID_CLAIMED_INPUT))
                return 0;
 @@ -484,6 +488,14 @@ static int wacom_raw_event(struct hid_device *hdev, 
 struct hid_report *report,
                        wacom_i4_parse_report(hdev, wdata, input, data + i);
                        i += 10;
                        wacom_i4_parse_report(hdev, wdata, input, data + i);
 +                       battery = data[i+10]  0x07;
 +                       if (batcap_i4[battery] != wdata-battery_capacity)
 +                               wdata-battery_capacity = batcap_i4[battery];

Its less work to set update each time; even to same value; then it is
to conditionally do it.

Hopefully, you consider moving to formula outside IRQ... but do you
want !ps_connected to show 100% like Graphire is doing?  I assume you
not doing it is a feature since status is something you could one
day support and the difference between charging/full/discharging is if
battery level is 100% or not + ps_connected.  Forcing to 100% would
hide that info.

Chris


 +
 +                       ps_connected = data[i+10]  0x08;
 +                       if (ps_connected != wdata-ps_connected)
 +                               wdata-ps_connected = ps_connected;

Same here.
 +
                        break;
                default:
                        hid_err(hdev, Unknown report: %d,%d size:%d\n,
 --
 1.7.6.4


 --
 This SF email is sponsosred by:
 Try Windows Azure free for 90 days Click Here
 http://p.sf.net/sfu/sfd2d-msazure
 ___
 Linuxwacom-devel mailing list
 Linuxwacom-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH 2/2] HID: wacom: Add battery/ac reporting for Intuos4 WL

[Chris Bagwell]

On Sun, Mar 18, 2012 at 2:08 PM, Przemo Firszt prz...@firszt.eu wrote:
 Dnia 2012-03-18, nie o godzinie 13:38 -0500, Chris Bagwell pisze:
 On Sun, Mar 18, 2012 at 11:24 AM, Przemo Firszt prz...@firszt.eu wrote:
  This patch adds battery/ac reporting for Intuos4 WL. It uses existing
  sysfs code, but the device reports battery capacity in more fine-grained 
  way,
  so there has to be a separate lookup table (called batcap_i4).
 
  Signed-off-by: Przemo Firszt prz...@firszt.eu
  ---
   drivers/hid/hid-wacom.c |   12 
   1 files changed, 12 insertions(+), 0 deletions(-)
 
  diff --git a/drivers/hid/hid-wacom.c b/drivers/hid/hid-wacom.c
  index 516b468..708b909 100644
  --- a/drivers/hid/hid-wacom.c
  +++ b/drivers/hid/hid-wacom.c
  @@ -53,6 +53,8 @@ struct wacom_data {
   #ifdef CONFIG_HID_WACOM_POWER_SUPPLY
   /*percent of battery capacity for Graphire, 0 means AC online*/
   static unsigned short batcap_gr[8] = { 1, 15, 25, 35, 50, 70, 100, 0 };
  +/*percent of battery capacity for Intuos4 WL, AC has a separate bit*/
  +static unsigned short batcap_i4[8] = { 1, 15, 30, 45, 60, 70, 85, 100 };
 
   static enum power_supply_property wacom_battery_props[] = {
         POWER_SUPPLY_PROP_PRESENT,
  @@ -457,6 +459,8 @@ static int wacom_raw_event(struct hid_device *hdev, 
  struct hid_report *report,
         struct input_dev *input;
         unsigned char *data = (unsigned char *) raw_data;
         int i;
  +       __u8 battery;
  +       __u8 ps_connected;
 
         if (!(hdev-claimed  HID_CLAIMED_INPUT))
                 return 0;
  @@ -484,6 +488,14 @@ static int wacom_raw_event(struct hid_device *hdev, 
  struct hid_report *report,
                         wacom_i4_parse_report(hdev, wdata, input, data + i);
                         i += 10;
                         wacom_i4_parse_report(hdev, wdata, input, data + i);
  +                       battery = data[i+10]  0x07;
  +                       if (batcap_i4[battery] != wdata-battery_capacity)
  +                               wdata-battery_capacity = 
  batcap_i4[battery];

 Its less work to set update each time; even to same value; then it is
 to conditionally do it.
 Hi Chris,
 It is conditional. One line after if doesnt' require {brackets}
 http://www.cprogramming.com/tutorial/c/lesson2.html

What I meant was that writing only:

   wdata-battery_capacity = batcap_i4[battery];

will have same end result, generate smaller size code, and run as fast
as or faster than this:

  if (batcap_i4[battery] != wdata-battery_capacity)
   wdata-battery_capacity = batcap_i4[battery];

Looking at the code block again and comparing it to Graphire, they
flow differently.  You may want to make the whole block only executed
when it see's capacity change.

Let me reply to other email though.

Chris


 Hopefully, you consider moving to formula outside IRQ...
 I don't want to do that - see my first email. It would add checking the
 device type in sysfs section instead of plain report whatever is in
 wdata-battery_capacity/ps_connected.

 but do you
 want !ps_connected to show 100% like Graphire is doing?
 No, Intuos4 WL seems to report proper battery value even when charging.
 I'll confirm that as soon as I find a standalone charger (USB connection
 switches the device to usb driver :-) )

 I assume you
 not doing it is a feature since status is something you could one
 day support and the difference between charging/full/discharging is if
 battery level is 100% or not + ps_connected.  Forcing to 100% would
 hide that info.
 Thanks for that - I'll check how to report it and I'll add it.
 --
 Regards,
 Przemo Firszt


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH ver.2 2/2] HID: wacom: Add battery/ac reporting for Intuos4 WL

[Chris Bagwell]

On Sun, Mar 18, 2012 at 2:27 PM, Przemo Firszt prz...@firszt.eu wrote:
 This patch adds battery/ac reporting for Intuos4 WL. It uses existing
 sysfs code, but the device reports battery capacity in more fine-grained way,
 so there has to be a separate lookup table (called batcap_i4).

 Signed-off-by: Przemo Firszt prz...@firszt.eu
 ---
  drivers/hid/hid-wacom.c |   12 
  1 files changed, 12 insertions(+), 0 deletions(-)

 diff --git a/drivers/hid/hid-wacom.c b/drivers/hid/hid-wacom.c
 index 1d19ccb..2c89c8a 100644
 --- a/drivers/hid/hid-wacom.c
 +++ b/drivers/hid/hid-wacom.c
 @@ -54,6 +54,8 @@ struct wacom_data {
  /*percent of battery capacity for Graphire
   7th value means AC online and show 100% capacity */
  static unsigned short batcap_gr[8] = { 1, 15, 25, 35, 50, 70, 100, 100 };
 +/*percent of battery capacity for Intuos4 WL, AC has a separate bit*/
 +static unsigned short batcap_i4[8] = { 1, 15, 30, 45, 60, 70, 85, 100 };

  static enum power_supply_property wacom_battery_props[] = {
        POWER_SUPPLY_PROP_PRESENT,
 @@ -455,6 +457,8 @@ static int wacom_raw_event(struct hid_device *hdev, 
 struct hid_report *report,
        struct input_dev *input;
        unsigned char *data = (unsigned char *) raw_data;
        int i;
 +       __u8 battery;
 +       __u8 ps_connected;

        if (!(hdev-claimed  HID_CLAIMED_INPUT))
                return 0;
 @@ -482,6 +486,14 @@ static int wacom_raw_event(struct hid_device *hdev, 
 struct hid_report *report,
                        wacom_i4_parse_report(hdev, wdata, input, data + i);
                        i += 10;
                        wacom_i4_parse_report(hdev, wdata, input, data + i);
 +                       battery = data[i+10]  0x07;
 +                       if (batcap_i4[battery] != wdata-battery_capacity)
 +                               wdata-battery_capacity = batcap_i4[battery];
 +
 +                       ps_connected = data[i+10]  0x08;
 +                       if (ps_connected != wdata-ps_connected)
 +                               wdata-ps_connected = ps_connected;
 +

I think in long term it would be better if you kept same code flow for
both Graphire and Intuos4.  Your 2nd patch for Graphire looked closer
to this:

if (data[i+10] != wdata-battery_raw) {
  wdat-battery_raw = data[i+10];
  battery = data[i+10]  0x07;
  wdata-battery_capacity = batcap_i4[battery];
  ps_connected = data[i+10]  0x08;
  wdata-ps_connected = ps_connected;
}

                        break;
                default:
                        hid_err(hdev, Unknown report: %d,%d size:%d\n,
 --
 1.7.6.4


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH ver.2 1/2] HID: wacom: Refactor battery/ac reporting for Graphire

[Chris Bagwell]

On Sun, Mar 18, 2012 at 2:27 PM, Przemo Firszt prz...@firszt.eu wrote:
 This patch doesn't change the way battery/ac is reported, but the changes are
 required to facilitate battery reporting for Intuos4 WL.
 wdata-battery_capacity now stores actual battery capacity as opposed to raw
 value reported by wacom graphire previously. Power supply state is now stored
 in a separate variable - it used to be calculated on-the-fly in
 wacom_ac_get_property function. The raw value has to be stored as well to be
 able to determine if it has changed.

 Signed-off-by: Przemo Firszt prz...@firszt.eu

Reviewed-by: Chris Bagwell ch...@cnpbagwell.com

 ---
  drivers/hid/hid-wacom.c |   34 +-
  1 files changed, 17 insertions(+), 17 deletions(-)

 diff --git a/drivers/hid/hid-wacom.c b/drivers/hid/hid-wacom.c
 index 067e296..1d19ccb 100644
 --- a/drivers/hid/hid-wacom.c
 +++ b/drivers/hid/hid-wacom.c
 @@ -42,15 +42,18 @@ struct wacom_data {
        __u32 serial;
        unsigned char high_speed;
  #ifdef CONFIG_HID_WACOM_POWER_SUPPLY
 -       int battery_capacity;
 +       __u8 battery_capacity;
 +       __u8 battery_raw;
 +       __u8 ps_connected;
        struct power_supply battery;
        struct power_supply ac;
  #endif
  };

  #ifdef CONFIG_HID_WACOM_POWER_SUPPLY
 -/*percent of battery capacity, 0 means AC online*/
 -static unsigned short batcap[8] = { 1, 15, 25, 35, 50, 70, 100, 0 };
 +/*percent of battery capacity for Graphire
 +  7th value means AC online and show 100% capacity */
 +static unsigned short batcap_gr[8] = { 1, 15, 25, 35, 50, 70, 100, 100 };

  static enum power_supply_property wacom_battery_props[] = {
        POWER_SUPPLY_PROP_PRESENT,
 @@ -70,7 +73,6 @@ static int wacom_battery_get_property(struct power_supply 
 *psy,
  {
        struct wacom_data *wdata = container_of(psy,
                                        struct wacom_data, battery);
 -       int power_state = batcap[wdata-battery_capacity];
        int ret = 0;

        switch (psp) {
 @@ -81,11 +83,7 @@ static int wacom_battery_get_property(struct power_supply 
 *psy,
                val-intval = POWER_SUPPLY_SCOPE_DEVICE;
                break;
        case POWER_SUPPLY_PROP_CAPACITY:
 -               /* show 100% battery capacity when charging */
 -               if (power_state == 0)
 -                       val-intval = 100;
 -               else
 -                       val-intval = power_state;
 +               val-intval = wdata-battery_capacity;
                break;
        default:
                ret = -EINVAL;
 @@ -99,17 +97,13 @@ static int wacom_ac_get_property(struct power_supply *psy,
                                union power_supply_propval *val)
  {
        struct wacom_data *wdata = container_of(psy, struct wacom_data, ac);
 -       int power_state = batcap[wdata-battery_capacity];
        int ret = 0;

        switch (psp) {
        case POWER_SUPPLY_PROP_PRESENT:
                /* fall through */
        case POWER_SUPPLY_PROP_ONLINE:
 -               if (power_state == 0)
 -                       val-intval = 1;
 -               else
 -                       val-intval = 0;
 +               val-intval = wdata-ps_connected;
                break;
        case POWER_SUPPLY_PROP_SCOPE:
                val-intval = POWER_SUPPLY_SCOPE_DEVICE;
 @@ -311,10 +305,16 @@ static int wacom_gr_parse_report(struct hid_device 
 *hdev,
        }

  #ifdef CONFIG_HID_WACOM_POWER_SUPPLY
 -       /* Store current battery capacity */
 +       /* Store current battery capacity and power supply state*/
        rw = (data[7]  2  0x07);
 -       if (rw != wdata-battery_capacity)
 -               wdata-battery_capacity = rw;
 +       if (rw != wdata-battery_raw) {
 +               wdata-battery_raw = rw;
 +               wdata-battery_capacity = batcap_gr[rw];
 +               if (rw == 7)
 +                       wdata-ps_connected = 1;
 +               else
 +                       wdata-ps_connected = 0;
 +       }
  #endif
        return 1;
  }
 --
 1.7.6.4


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH v2 4/4] input: wacom: Intuos5 multitouch sensor support

[Chris Bagwell]

On Mon, Mar 12, 2012 at 5:36 PM, Jason Gerecke killert...@gmail.com wrote:
 Intuos5 tablets with PTH-* model numbers include a multitouch sensor
 which use the same touch reports as the 3rd-generation Bamboo. No
 useful information is in the HID descriptor for the touch interface
 so hardcoded values are used during setup.

 Signed-off-by: Jason Gerecke killert...@gmail.com
 ---
 Changes from v1:
  * Fixed calculation of x_phy and y_phy (logic for the 3rd-gen Bamboo
   which I copied is incorrect! Patch on the way.)

Thanks for catching.

For patches 1, 2, and 4 in this series:

Reviewed-by: Chris Bagwell ch...@cnpbagwell.com

I did review and didn't see any issues with patch #3 but I'm not
familiar with LED support to comment.

Chris


  drivers/input/tablet/wacom_sys.c |   24 ++
  drivers/input/tablet/wacom_wac.c |   63 
 +++---
  2 files changed, 82 insertions(+), 5 deletions(-)

 diff --git a/drivers/input/tablet/wacom_sys.c 
 b/drivers/input/tablet/wacom_sys.c
 index 11b4c05..528e3a4 100644
 --- a/drivers/input/tablet/wacom_sys.c
 +++ b/drivers/input/tablet/wacom_sys.c
 @@ -228,6 +228,9 @@ static int wacom_parse_logical_collection(unsigned char 
 *report,
  * 3rd gen Bamboo Touch no longer define a Digitizer-Finger Pysical
  * Collection. Instead they define a Logical Collection with a single
  * Logical Maximum for both X and Y.
 + *
 + * Intuos5 touch interface does not contain useful data. We deal with
 + * this after returning from this function.
  */
  static int wacom_parse_hid(struct usb_interface *intf,
                           struct hid_descriptor *hid_desc,
 @@ -924,6 +927,27 @@ static int wacom_probe(struct usb_interface *intf, const 
 struct usb_device_id *i
        if (error)
                goto fail3;

 +       /* Intuos5 has no useful data about its touch interface in its
 +        * HID descriptor. If this is the touch interface (wMaxPacketSize
 +        * of WACOM_PKGLEN_BBTOUCH3), override the table values.
 +        */
 +       if (features-type = INTUOS5S  features-type = INTUOS5L) {
 +               if (endpoint-wMaxPacketSize == WACOM_PKGLEN_BBTOUCH3) {
 +                       features-device_type = BTN_TOOL_FINGER;
 +                       features-pktlen = WACOM_PKGLEN_BBTOUCH3;
 +
 +                       features-x_phy =
 +                               (features-x_max * 100) / 
 features-x_resolution;
 +                       features-y_phy =
 +                               (features-y_max * 100) / 
 features-y_resolution;
 +
 +                       features-x_max = 4096;
 +                       features-y_max = 4096;
 +               } else {
 +                       features-device_type = BTN_TOOL_PEN;
 +               }
 +       }
 +
        wacom_setup_device_quirks(features);

        strlcpy(wacom_wac-name, features-name, sizeof(wacom_wac-name));
 diff --git a/drivers/input/tablet/wacom_wac.c 
 b/drivers/input/tablet/wacom_wac.c
 index 86827c7..30067ae 100644
 --- a/drivers/input/tablet/wacom_wac.c
 +++ b/drivers/input/tablet/wacom_wac.c
 @@ -321,6 +321,9 @@ static int wacom_intuos_inout(struct wacom_wac *wacom)

        /* Enter report */
        if ((data[1]  0xfc) == 0xc0) {
 +               if (features-type = INTUOS5S  features-type = INTUOS5L)
 +                       wacom-shared-stylus_in_proximity = true;
 +
                /* serial number of the tool */
                wacom-serial[idx] = ((data[3]  0x0f)  28) +
                        (data[4]  20) + (data[5]  12) +
 @@ -406,6 +409,9 @@ static int wacom_intuos_inout(struct wacom_wac *wacom)

        /* Exit report */
        if ((data[1]  0xfe) == 0x80) {
 +               if (features-type = INTUOS5S  features-type = INTUOS5L)
 +                       wacom-shared-stylus_in_proximity = false;
 +
                /*
                 * Reset all states otherwise we lose the initial states
                 * when in-prox next time
 @@ -,9 +1117,6 @@ void wacom_wac_irq(struct wacom_wac *wacom_wac, size_t 
 len)
        case INTUOS4S:
        case INTUOS4:
        case INTUOS4L:
 -       case INTUOS5S:
 -       case INTUOS5:
 -       case INTUOS5L:
        case CINTIQ:
        case WACOM_BEE:
        case WACOM_21UX2:
 @@ -1121,6 +1124,15 @@ void wacom_wac_irq(struct wacom_wac *wacom_wac, size_t 
 len)
                sync = wacom_intuos_irq(wacom_wac);
                break;

 +       case INTUOS5S:
 +       case INTUOS5:
 +       case INTUOS5L:
 +               if (len == WACOM_PKGLEN_BBTOUCH3)
 +                       sync = wacom_bpt3_touch(wacom_wac);
 +               else
 +                       sync = wacom_intuos_irq(wacom_wac);
 +               break;
 +
        case TABLETPC:
        case TABLETPC2FG:
                sync = wacom_tpc_irq(wacom_wac, len);
 @@ -1191,7 +1203,7 @@ void wacom_setup_device_quirks(struct wacom_features 
 *features)

        /* these device have multiple inputs */
        if (features-type == TABLETPC || features-type

Re: [Linuxwacom-devel] [PATCH] input: wacom: Fix physical size calculation for 3rd-gen Bamboo

[Chris Bagwell]

On Mon, Mar 12, 2012 at 5:53 PM, Jason Gerecke killert...@gmail.com wrote:
 This calculation determines the physical dimensions of the tablet,
 used later on in calculate_touch_res to obtain the touch sensor
 resolution.

 Instead of dividing the logical size by the resolution, the current
 code performs a multiplication. This doesn't pose a problem for the
 3rd-gen Bamboo since the resolution and scale factor happen to be
 identical, but will produce an incorrect result for other cases.

 Signed-off-by: Jason Gerecke killert...@gmail.com

Reviewed-by: Chris Bagwell ch...@cnpbagwell.com

 ---
  drivers/input/tablet/wacom_sys.c |    4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/input/tablet/wacom_sys.c 
 b/drivers/input/tablet/wacom_sys.c
 index c9588ee..dc07821 100644
 --- a/drivers/input/tablet/wacom_sys.c
 +++ b/drivers/input/tablet/wacom_sys.c
 @@ -184,9 +184,9 @@ static int wacom_parse_logical_collection(unsigned char 
 *report,
                 * data before its overwritten.
                 */
                features-x_phy =
 -                       (features-x_max * features-x_resolution) / 100;
 +                       (features-x_max * 100) / features-x_resolution;
                features-y_phy =
 -                       (features-y_max * features-y_resolution) / 100;
 +                       (features-y_max * 100) / features-y_resolution;

                features-x_max = features-y_max =
                        get_unaligned_le16(report[10]);
 --
 1.7.9.1


--
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] [PATCH] HID: wacom: Add reporting of wheel for Intuos4 WL

[Chris Bagwell]

On Fri, Mar 9, 2012 at 2:27 PM, Przemo Firszt prz...@firszt.eu wrote:
 This patch adds reporting of ABS_WHEEL event. Raported walues are 0..71
 and are related to absolute location of the finger on the wheel.

 Signed-off-by: Przemo Firszt prz...@firszt.eu
 Reviewed-by: Jason Gerecke killert...@gmail.com
 ---
  drivers/hid/hid-wacom.c |   25 +
  1 files changed, 25 insertions(+), 0 deletions(-)

 diff --git a/drivers/hid/hid-wacom.c b/drivers/hid/hid-wacom.c
 index 5c25036..dab7588 100644
 --- a/drivers/hid/hid-wacom.c
 +++ b/drivers/hid/hid-wacom.c
 @@ -36,6 +36,7 @@
  struct wacom_data {
        __u16 tool;
        __u16 butstate;
 +       __u8 whlstate;
        __u8 features;
        __u32 id;
        __u32 serial;
 @@ -322,6 +323,23 @@ static void wacom_i4_parse_button_report(struct 
 wacom_data *wdata,
                        struct input_dev *input, unsigned char *data)
  {
        __u16 new_butstate;
 +       __u8 new_whlstate;
 +       __u8 sync = 0;
 +
 +       new_whlstate = data[1];
 +       if (new_whlstate != wdata-whlstate) {
 +               wdata-whlstate = new_whlstate;
 +               if (new_whlstate  0x80) {
 +                       input_report_key(input, BTN_TOUCH, 1);
 +                       input_report_abs(input, ABS_WHEEL, (new_whlstate  
 0x7f));
 +                       input_report_key(input, BTN_TOOL_FINGER, 1);
 +               } else {
 +                       input_report_key(input, BTN_TOUCH, 0);
 +                       input_report_abs(input, ABS_WHEEL, 0);
 +                       input_report_key(input, BTN_TOOL_FINGER, 0);
 +               }
 +               sync = 1;
 +       }

        new_butstate = (data[3]  1) | (data[2]  0x01);
        if (new_butstate != wdata-butstate) {
 @@ -336,6 +354,10 @@ static void wacom_i4_parse_button_report(struct 
 wacom_data *wdata,
                input_report_key(input, BTN_7, new_butstate  0x080);
                input_report_key(input, BTN_8, new_butstate  0x100);
                input_report_key(input, BTN_TOOL_FINGER, 1);
 +               sync = 1;
 +       }
 +
 +       if (sync) {
                input_report_abs(input, ABS_MISC, PAD_DEVICE_ID);
                input_event(input, EV_MSC, MSC_SERIAL, 0x);
                input_sync(input);
 @@ -512,6 +534,9 @@ static int wacom_input_mapped(struct hid_device *hdev, 
 struct hid_input *hi,
                input_set_abs_params(input, ABS_DISTANCE, 0, 32, 0, 0);
                break;
        case USB_DEVICE_ID_WACOM_INTUOS4_BLUETOOTH:
 +               __set_bit(ABS_WHEEL, input-absbit);
 +               input_set_abs_params(input, ABS_WHEEL, 0, 71, 0, 0);
 +               input_set_capability(input, EV_MSC, MSC_SERIAL);

Is this input_set_capability MSC_SERIAL line to fix the next line
thats above case statement?

 __set_bit(MSC_SERIAL, input-mscbit);

Should the original line be deleted/replaced?

Chris

                __set_bit(ABS_MISC, input-absbit);
                __set_bit(BTN_2, input-keybit);
                __set_bit(BTN_3, input-keybit);
 --
 1.7.6.4

 --
 To unsubscribe from this list: send the line unsubscribe linux-input in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] Tilt value meaning

[Chris Bagwell]

On Thu, Mar 8, 2012 at 12:06 PM, Jason Gerecke killert...@gmail.com wrote:
 On Thu, Mar 8, 2012 at 4:14 AM, Nikolai Kondrashov spbn...@gmail.com wrote:

 Can you suggest a way to test the tilt with a real-world application, not
 just xinput test or xev?


 I usually use gimp for real-world testing, though I think you'll only
 get tilt-sensitivity in gimp-2.7 (which is an unstable release...)


I believe tilt support is also in 2.6 but does seem to only work with
certain tools.  The Ink Pen mentions setting tilt sensitivity.

http://docs.gimp.org/en/gimp-tool-ink.html

Chris

--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] Tilt value meaning

[Chris Bagwell]

On Wed, Mar 7, 2012 at 2:18 PM, Nikolai Kondrashov spbn...@gmail.com wrote:
 Hi everyone,

 Today I've started implementing a driver for Waltop Sirius Battery Free
 tablet. As it turns out, it reports pen tilting, which is a rare thing for
 non-Wacom tablets!

 Could someone please explain what ABS_TILT_X and ABS_TILT_Y event values are
 supposed to mean? What are the units and ranges?

 Also, what the X applications are expecting as tilting valuator values?

 My expectation was that the values match the HID usage tables spec
 description of X Tilt and Y Tilt usages (see 16.3.2 Tilt Orientation).
 I.e. positive/negative fractions of the X/Y arcs, which probably cover 90
 degrees both ways, since nobody is looking at the resolution. Interestingly
 enough, the spec says positive inclination is bottom right corner, but the
 tablet assumes top right.

 However, after reading xf86-input-wacom sources I got somewhat confused.

 Could someone clarify this?


I do not have a tablet with tilt, nor experience on how userland uses
it.  And probably I should have read that HID section before replying
but...

I do see all Wacom tablets with Tilt support report tilt X/Y declaring
a value between 0 and 127.  I also see these tablets advertised on web
with Tilt Range of +/- 60 degrees.  So I'm going to take a wild guess
since 60 + 60 ~= 127 the units are degrees.

Hopefully, those missing degree's aren't hard coded in apps such as gimp!

Chris

--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH] HID: wacom: set ABS_MISC bit for Intuos4 WL

[Chris Bagwell]

On Fri, Feb 24, 2012 at 7:32 AM, Przemo Firszt prz...@firszt.eu wrote:
 Dnia 2012-02-23, czw o godzinie 21:19 -0600, Chris Bagwell pisze:
 On Wed, Feb 22, 2012 at 3:21 PM, Przemo Firszt prz...@firszt.eu wrote:
 [..]

            __set_bit(ABS_MISC, input-absbit);

 So in your copy, it is already setting MSC_SERIAL bit, you've added
 code to send it, and xf86-input-wacom is still forcing it to a value
 of 1?

 Yes, that what was happening. See this (wcmUSB.c):
        if (common-wcmProtocolLevel == WCM_PROTOCOL_GENERIC)
        {
                /* Generic Protocol devices do not use any form of
                 * serial #'s to multiplex events over a single input
                 * and so can always map to channel 0.  This means
                 * only 1 tool can ever been in proximity at one time
                 * (MT events are special case handled elsewhere).
                 * It also means all buttons must be associated with
                 * a single tool and can not send tablet buttons
                 * as part of a pad tool.
                 */
                channel = 0;
                serial = 1;

                /* Generic devices need to map stylus buttons to
 channel
                 * and all other button presses to PAD.  Hardcode PAD
                 * channel here.
                 */
                private-wcmBTNChannel = PAD_CHANNEL;
        }


Thanks.  I should probably delete the serial = 1 part at some point.
The important part in that line is channel = 0.

At some point, I'd like to unify this function that computes channel #
for protocol 4, protocol 5, and generic devices.  Protocol 5 does a
lookup into an array of size 3 to find channel with matching serial #
or empty channel.  For protocol 4, kernel driver hard codes to serial
= 1 or 0xff and driver converts to channel 0 or 1.  For generic,
kernel driver either never sends/declares a serial # (so same as
sending zero to xf86-input-wacom) or behaves like protocol 5 but we
hard always code to channel 0.

In all cases, we can use lookup table approach with serial # as key.

Chris

--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] Protocol for Intuos4 WL?

[Chris Bagwell]

On Wed, Feb 22, 2012 at 1:55 PM, Przemo Firszt prz...@firszt.eu wrote:
 I'm trying to track down a probem with Intuos4 WL. Connected by USB
 works OK:
 [  3182.316] (II) /dev/input/event8 (10:wcmEvent): c=0 i=1050626 t=1c
 s=343955190 x=18061 y=9959 b=0 p=0 rz=0 tx=28 ty=32 aw=0 aw2=0 rw=0 t=0
 px=1 st=0 cs=4

 so serial is 343955190 (hex 148056F6),
 id 1050626 (hex 100802) or hex 10080A depending on the tool.

 now hid-wacom:

 [ 22269.565] (II) /dev/input/event8 (10:wcmEvent): c=0 i=0 t=1 s=1
 x=32822 y=11354 b=0 p=0 rz=0 tx=0 ty=0 aw=0 aw2=0 rw=0 t=0 px=1 st=0 cs=4

 so serial = 1, id =0

Based on later emails, looks like you have it under control but in
case your interested, here is some more info.

I believe that xf86-input-wacom will support serial #'s if you declare
MSC_SERIAL in the probe() area of driver.  xf86-input-wacom doesn't do
much more then pass it around; even for generic tablets.  You could
make this change by itself.

'id' on the other hand comes from ABS_MISC.  Yes, declaring that in
probe() will get it working but it also enables protocol 5 support.

There is a few subtle issues but based on current hid-wacom it boils
down to this: when you finally add pad button support be sure and use
BTN_0/1/2/etc and not BTN_RIGHT/LEFT/etc.  Lets just say Protocol 5
and buttons are handled odd.


 P.S. How to set debug level for tablet before connecting? I what to debug 
 connection process, but
 xsetwacom --set Wacom Intuos4 WL pad TabletDebugLevel 10 can't work if 
 there is no tablet connected.

I've not tried it but Peter made some updates so you can set the debug
options in your 50-wacom.conf file and the driver looks for it very
early on.

Chris

--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH] HID: wacom: set ABS_MISC bit for Intuos4 WL

[Chris Bagwell]

On Wed, Feb 22, 2012 at 3:21 PM, Przemo Firszt prz...@firszt.eu wrote:
 ABS_MISC has to be set for Intuos4 WL otherwise xorg driver won't use proper
 protocol and the information about tool id and serial is lost.

 Signed-off-by: Przemo Firszt prz...@firszt.eu
 ---
  drivers/hid/hid-wacom.c |    1 +
  1 files changed, 1 insertions(+), 0 deletions(-)

 diff --git a/drivers/hid/hid-wacom.c b/drivers/hid/hid-wacom.c
 index 696b907..a793753 100644
 --- a/drivers/hid/hid-wacom.c
 +++ b/drivers/hid/hid-wacom.c
 @@ -471,6 +471,7 @@ static int wacom_input_mapped(struct hid_device *hdev, 
 struct hid_input *hi,
                input_set_abs_params(input, ABS_DISTANCE, 0, 32, 0, 0);
                break;
        case USB_DEVICE_ID_WACOM_INTUOS4_BLUETOOTH:
 +               __set_bit(ABS_MISC, input-absbit);

So in your copy, it is already setting MSC_SERIAL bit, you've added
code to send it, and xf86-input-wacom is still forcing it to a value
of 1?

Hmm, I don't see in xf86-input-wacom code why thats happening.  Oh well.

I'm sure you want ABS_MISC to send device ID so it integrates with new
gnome-settings-daemon stuff anyways so I guess its not worth looking
into.

For both patches:

Reviewed-by: Chris Bagwell ch...@cnpbagwell.com

                input_set_abs_params(input, ABS_X, 0, 40640, 4, 0);
                input_set_abs_params(input, ABS_Y, 0, 25400, 4, 0);
                input_set_abs_params(input, ABS_PRESSURE, 0, 2047, 0, 0);
 --
 1.7.6.4


 --
 Virtualization  Cloud Management Using Capacity Planning
 Cloud computing makes use of virtualization - but cloud computing
 also focuses on allowing computing to be delivered as a service.
 http://www.accelacomm.com/jaw/sfnl/114/51521223/
 ___
 Linuxwacom-devel mailing list
 Linuxwacom-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH] Export current tool ID in the property too

[Chris Bagwell]

I believe I get it.  I was thinking about advertising the old value
change but this instead looks like it advertises missing device ID
change which indirectly covers all the cases were old values need
updating... and old values only get updated on demand.

Reviewed-by: Chris Bagwell ch...@cnpbagwell.com


On Wed, Feb 22, 2012 at 12:54 AM, Peter Hutterer
peter.hutte...@who-t.net wrote:
 Previously, we exported old serial number, old tool ID and current serial
 number. Export the current tool ID as well.

 Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
 ---
  include/wacom-properties.h |    6 --
  src/wcmCommon.c            |    6 +++---
  src/wcmXCommand.c          |   16 ++--
  src/xf86Wacom.h            |    2 +-
  src/xf86WacomDefs.h        |    1 +
  5 files changed, 19 insertions(+), 12 deletions(-)

 diff --git a/include/wacom-properties.h b/include/wacom-properties.h
 index 0bb84b1..2bb86ab 100644
 --- a/include/wacom-properties.h
 +++ b/include/wacom-properties.h
 @@ -33,8 +33,10 @@
  /* 32 bit, 4 values */
  #define WACOM_PROP_PRESSURECURVE Wacom Pressurecurve

 -/* CARD32, 4 values, tablet id, old serial, old hw device id, current serial
 -   read-only */
 +/* CARD32, 4 values, tablet id, old serial, old hw device id,
 +   current serial, current device id
 +   read-only
 + */
  #define WACOM_PROP_SERIALIDS Wacom Serial IDs

  /* CARD32, 1 value */
 diff --git a/src/wcmCommon.c b/src/wcmCommon.c
 index 11340ea..65b0390 100644
 --- a/src/wcmCommon.c
 +++ b/src/wcmCommon.c
 @@ -730,8 +730,8 @@ void wcmSendEvents(InputInfoPtr pInfo, const 
 WacomDeviceState* ds)
                return;
        }

 -       if (priv-cur_serial != serial)
 -               wcmUpdateSerial(pInfo, serial);
 +       if (priv-cur_serial != serial || priv-cur_device_id != id)
 +               wcmUpdateSerial(pInfo, serial, id);

        /* don't move the cursor when going out-prox */
        if (!ds-proximity)
 @@ -833,7 +833,7 @@ void wcmSendEvents(InputInfoPtr pInfo, const 
 WacomDeviceState* ds)
                priv-devReverseCount = 0;
                priv-old_serial = serial;
                priv-old_device_id = id;
 -               wcmUpdateSerial(pInfo, 0);
 +               wcmUpdateSerial(pInfo, 0, 0);
        }
  }

 diff --git a/src/wcmXCommand.c b/src/wcmXCommand.c
 index 0fd5664..57b3f20 100644
 --- a/src/wcmXCommand.c
 +++ b/src/wcmXCommand.c
 @@ -190,7 +190,8 @@ void InitWcmDeviceProperties(InputInfoPtr pInfo)
        values[1] = priv-old_serial;
        values[2] = priv-old_device_id;
        values[3] = priv-cur_serial;
 -       prop_serials = InitWcmAtom(pInfo-dev, WACOM_PROP_SERIALIDS, 
 XA_INTEGER, 32, 4, values);
 +       values[4] = priv-cur_device_id;
 +       prop_serials = InitWcmAtom(pInfo-dev, WACOM_PROP_SERIALIDS, 
 XA_INTEGER, 32, 5, values);

        values[0] = priv-serial;
        prop_serial_binding = InitWcmAtom(pInfo-dev, WACOM_PROP_SERIAL_BIND, 
 XA_INTEGER, 32, 1, values);
 @@ -718,7 +719,7 @@ int wcmSetProperty(DeviceIntPtr dev, Atom property, 
 XIPropertyValuePtr prop,
                 * set it at runtime. If we get here from wcmUpdateSerial,
                 * we know the serial has ben set internally already, so we
                 * can reply with success. */
 -               if (prop-size == 4  prop-format == 32)
 +               if (prop-size == 5  prop-format == 32)
                        if (((CARD32*)prop-data)[3] == priv-cur_serial)
                                return Success;

 @@ -875,11 +876,12 @@ int wcmGetProperty (DeviceIntPtr dev, Atom property)
                values[1] = priv-old_serial;
                values[2] = priv-old_device_id;
                values[3] = priv-cur_serial;
 +               values[4] = priv-cur_device_id;

                DBG(10, priv, Update to serial: %d\n, priv-old_serial);

                return XIChangeDeviceProperty(dev, property, XA_INTEGER, 32,
 -                                             PropModeReplace, 4,
 +                                             PropModeReplace, 5,
                                              values, FALSE);
        }

 @@ -892,14 +894,14 @@ serialTimerFunc(OsTimerPtr timer, CARD32 now, pointer 
 arg)
        InputInfoPtr pInfo = arg;
        WacomDevicePtr priv = pInfo-private;
        XIPropertyValuePtr prop;
 -       CARD32 prop_value[4];
 +       CARD32 prop_value[5];
        int sigstate;
        int rc;

        sigstate = xf86BlockSIGIO();

        rc = XIGetDeviceProperty(pInfo-dev, prop_serials, prop);
 -       if (rc != Success || prop-format != 32 || prop-size != 4)
 +       if (rc != Success || prop-format != 32 || prop-size != 5)
        {
                xf86Msg(X_ERROR, %s: Failed to update serial number.\n,
                        pInfo-name);
 @@ -908,6 +910,7 @@ serialTimerFunc(OsTimerPtr timer, CARD32 now, pointer arg)

        memcpy(prop_value, prop-data, sizeof(prop_value));
        prop_value[3] = priv-cur_serial;
 +       prop_value[4] = priv-cur_device_id

Re: [Linuxwacom-devel] [PATCH] HID: wacom: fix proximity tool release

[Chris Bagwell]

Reviewed-by: Chris Bagwell ch...@cnpbagwell.com

On Sun, Feb 19, 2012 at 2:20 PM, Przemo Firszt prz...@firszt.eu wrote:
 Don't zero the current tool before reporting its release to the input
 subsystem.

 Signed-off-by: Aristeu Rozanski a...@redhat.com
 Tested-by: Przemo Firszt prz...@firszt.eu
 ---
  drivers/hid/hid-wacom.c |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/drivers/hid/hid-wacom.c b/drivers/hid/hid-wacom.c
 index 0621047..696b907 100644
 --- a/drivers/hid/hid-wacom.c
 +++ b/drivers/hid/hid-wacom.c
 @@ -322,10 +322,10 @@ static void wacom_i4_parse_pen_report(struct wacom_data 
 *wdata,

        switch (data[1]) {
        case 0x80: /* Out of proximity report */
 -               wdata-tool = 0;
                input_report_key(input, BTN_TOUCH, 0);
                input_report_abs(input, ABS_PRESSURE, 0);
                input_report_key(input, wdata-tool, 0);
 +               wdata-tool = 0;
                input_sync(input);
                break;
        case 0xC2: /* Tool report */
 --
 1.7.6.4

 --
 To unsubscribe from this list: send the line unsubscribe linux-input in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] Tool ID not updating

[Chris Bagwell]

On Mon, Feb 20, 2012 at 11:39 AM, Bastien Nocera had...@hadess.net wrote:
 Heya,

 I'm having a bit of trouble with this code:
 http://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/common/gsd-input-helper.c#n292

 It's supposed to send the last used tool ID, except that it doesn't seem
 to update when I bring my pen closer, only when I remove it. Which
 offset of Wacom Serial IDs is supposed to contain the _current_ tool
 ID? All my attempts so far have resulted in even more bizarre
 occurrences.

 I'm confused. This is stopping me from implementing automatic page
 switching in the GNOME panel based on the last used stylus.


It looks to me that there is logic to update the current serial #
(data[3]) in related property but nothing to update the old serial #
(data[1]).

On the other hand, if you polled the property, it does get the real
time value for data[3].  So that probably explains strange combination
of behavior your see.

I think a big improvement in behavior will occur if you modify
wcmXCommand.c::serialTimerFunc() to update both old_serial and
cur_serial.

In addition, a nice cleanup would be to update
wcmXCommand.c::wcmUpdateSerial() to set old_serial = cur_serial when
it see's current serial # changing to 0.  And then to delete that same
line in wcmSendEvents() where its calling wcmUpdateSerial(0).

I do not have a device that reports serial #'s so I have a hard time
helping out with patches in this area.

Chris

--
Try before you buy = See our experts in action!
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-dev2
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] Issues with DTI-520

[Chris Bagwell]

On Sun, Feb 19, 2012 at 2:33 AM, Adam Nielsen a.niel...@shikadi.net wrote:

 So far everything works fine in evdev, but I am still having problems
 getting the X driver to pick up the device.

 Currently the interface with the buttons works (the L and R buttons on the
 tablet work as left and right mouse buttons) however the stylus interface is
 still being ignored.

 I got the logging working with 'xinput set-prop device_name Wacom Debug
 Levels 10 10' from your other e-mail and the correct events are logged:

 [ 26093.031] (II) Wacom DTI520UB/L stylus (10:wcmReady): 1 numbers of data
 [ 26093.031] (II) /dev/input/event13 (10:wcmReadPacket): fd=75
 [ 26093.031] (II) /dev/input/event13 (1:wcmReadPacket): pos=0 remaining=256
 [ 26093.031] (II) /dev/input/event13 (10:wcmReadPacket): buffer has 72 bytes
 [ 26093.031] (II) /dev/input/event13 (10:usbParseEvent):
 [ 26093.031] (II) /dev/input/event13 (10:usbParseEvent):
 [ 26093.031] (II) /dev/input/event13 (10:usbParseEvent):
 [ 26093.031] (II) /dev/input/event13 (6:usbDispatchEvents): 3 events
 received
 [ 26093.031] (II) /dev/input/event13 (10:wcmEvent): channel = 0
 [ 26093.031] (II) /dev/input/event13 (10:wcmEvent): c=0 i=0 t=0 s=1 x=3806
 y=2352 b=0 p=0 rz=0 tx=0 ty=0 aw=0 aw2=0 rw=0 t=0 px=0 st=0 cs=0
 [ 26093.031] (II) Wacom DTI520UB/L stylus (10:wcmReady): 0 numbers of data
 [ 26093.031] (II) Wacom DTI520UB/L stylus (10:wcmDevReadInput): Read (1)

 Yet xinput test doesn't display any events for the stylus interface.  Any
 ideas what I could be doing wrong?

Only seeing this small sample, Its probably the proximity value thats
not working.  When px=0, the driver will not post X/Y events to X
server.

Also, the device type is set to 0 (t=0). Events are discarded when
no device_type is set.

What version of xf86-input-wacom are you running?  You may need to
upgrade for it to work with whats sometimes called generic tablets.
I think you need at least version 0.11 for that support.

Or you can modify your kernel side code a little to not be generic.


 I am configuring the device like this in wacom_setup_input_capabilities():

        case WACOM_DTI:
                __clear_bit(ABS_MISC, input_dev-absbit);
                switch (features-device_type) {
                case BTN_TOOL_PEN:
                        __set_bit(BTN_TOOL_PEN, input_dev-keybit);
                        __set_bit(BTN_STYLUS, input_dev-keybit);
                        __set_bit(BTN_STYLUS2, input_dev-keybit);

                        __set_bit(INPUT_PROP_DIRECT, input_dev-propbit);
                        break;

That all looks good.  The ABS_MISC that your turning off is what
xf86-input-wacom used to key off of to set device_type on its side.
You can delete that line and then start sending it; using
wacom_dtu_irq() as a guide on how to do that.

But it also shouldn't be needed in newer X input drivers.

Chris

--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH] HID: wacom: Force new name for Wacom Intuos4 WL PTK-540WL

[Chris Bagwell]

On Fri, Feb 17, 2012 at 11:47 AM, Przemo Firszt prz...@firszt.eu wrote:
 The name reported by Inutos4 WL connected by bluetooth is PTK-540WL and
 to make it consistent with other Wacom devices it has to be converted to
 Wacom Intuos4 WL. It also makes userland applications aware that it's
 a Wacom device.

 Signed-off-by: Przemo Firszt prz...@firszt.eu
 ---

Its worth noting this aligns naming of device to same used when this
device is plugged into USB port and controlled by USB wacom driver;
and thus helps align userland logic to route to apps like
xf86-input-wacom.

Reviewed-by: Chris Bagwell ch...@cnpbagwell.com

  drivers/hid/hid-wacom.c |    1 +
  1 files changed, 1 insertions(+), 0 deletions(-)

 diff --git a/drivers/hid/hid-wacom.c b/drivers/hid/hid-wacom.c
 index acab74c..0621047 100644
 --- a/drivers/hid/hid-wacom.c
 +++ b/drivers/hid/hid-wacom.c
 @@ -518,6 +518,7 @@ static int wacom_probe(struct hid_device *hdev,
                wacom_poke(hdev, 1);
                break;
        case USB_DEVICE_ID_WACOM_INTUOS4_BLUETOOTH:
 +               sprintf(hdev-name, %s, Wacom Intuos4 WL);
                wdata-features = 0;
                wacom_set_features(hdev);
                break;
 --
 1.7.6.4

 --
 To unsubscribe from this list: send the line unsubscribe linux-input in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

[Linuxwacom-devel] [PATCH input-wacom] Backport 2nd and 3rd gen Bamboo support to 2.6.30

[chris]

From: Chris Bagwell ch...@cnpbagwell.com

This aligns 2.6.30 behavior with 2.6.38 driver except for MT
support.  Instead of MT events for touch, it sends
ABS_X/Y for 1st touch only.  This is similar to a synaptics
touchpad behavior.

The driver does correctly send DOUBLE/TRIPLE/QUADTAP
events so if user maps input to xf86-input-synaptics
then they will get working 2-finger gestures for scrolling.

This works because Bamboo was also changed from Protocol 4 to
Generic Protocol; same as 2.6.36 and 2.6.38 driver.  This also
means either xf86-input-wacom 0.11 or 0.12 is needed.

Tested with CentOS 6.2 (2.6.32 kernel and Xorg 1.10) and
xf86-input-wacom 0.12.
---

Anybody see a reason not to change from Protocol 4 to Generic so they
are all working the same?  This basically means remove the report for
MSC_SERIAL with a value fixed to 0.

 2.6.30/wacom_sys.c |   35 +-
 2.6.30/wacom_wac.c |  339 +++-
 2.6.30/wacom_wac.h |2 +
 3 files changed, 236 insertions(+), 140 deletions(-)

diff --git a/2.6.30/wacom_sys.c b/2.6.30/wacom_sys.c
index d460d6d..8d616df 100755
--- a/2.6.30/wacom_sys.c
+++ b/2.6.30/wacom_sys.c
@@ -32,7 +32,10 @@
 #define HID_USAGE_Y_TILT   0x3e
 #define HID_USAGE_FINGER   0x22
 #define HID_USAGE_STYLUS   0x20
-#define HID_COLLECTION 0xc0
+#define HID_COLLECTION 0xa1
+#define HID_COLLECTION_LOGICAL 0x02
+#define HID_COLLECTION_END 0xc0
+
 
 enum {
WCM_UNDEFINED = 0,
@@ -143,6 +146,25 @@ static void wacom_close(struct input_dev *dev)
mutex_unlock(wacom-lock);
 }
 
+static int wacom_parse_logical_collection(unsigned char *report,
+ struct wacom_features *features)
+{
+   int length = 0;
+
+   if (features-type == BAMBOO_PT) {
+
+   /* Logical collection is only used by 3rd gen Bamboo Touch */
+   features-pktlen = WACOM_PKGLEN_BBTOUCH3;
+   features-device_type = BTN_TOOL_DOUBLETAP;
+
+   features-x_max = features-y_max =
+   get_unaligned_le16(report[10]);
+
+   length = 11;
+   }
+   return length;
+}
+
 static int wacom_parse_hid(struct usb_interface *intf, struct hid_descriptor 
*hid_desc,
   struct wacom_features *features)
 {
@@ -302,10 +324,19 @@ static int wacom_parse_hid(struct usb_interface *intf, 
struct hid_descriptor *hi
}
break;
 
-   case HID_COLLECTION:
+   case HID_COLLECTION_END:
/* reset UsagePage and Finger */
finger = usage = 0;
break;
+   case HID_COLLECTION:
+   i++;
+   switch (report[i]) {
+   case HID_COLLECTION_LOGICAL:
+   i += wacom_parse_logical_collection(report[i],
+   features);
+   break;
+   }
+   break;
}
}
 
diff --git a/2.6.30/wacom_wac.c b/2.6.30/wacom_wac.c
index bad56d3..d678a72 100755
--- a/2.6.30/wacom_wac.c
+++ b/2.6.30/wacom_wac.c
@@ -197,137 +197,152 @@ static int wacom_ptu_irq(struct wacom_wac *wacom)
return 1;
 }
 
-static void wacom_bpt_finger_in(struct wacom_wac *wacom, char *data, int idx)
+static int wacom_bpt_touch(struct wacom_wac *wacom)
 {
-   int x = 0, y = 0;
-   int finger = idx + 1;
struct input_dev *input = wacom-input;
+   unsigned char *data = wacom-data;
+   int i, touch_count = 0;
 
-   x = get_unaligned_be16(data[3 + (idx * 9)])  0x7ff;
-   y = get_unaligned_be16(data[5 + (idx * 9)])  0x7ff;
+   if (data[0] != 0x02)
+   return 0;
 
-   if (wacom-last_finger != finger) {
-   if (x == input-abs[ABS_X])
-   x++;
+   for (i = 0; i  1; i++) {
+   int offset = (data[1]  0x80) ? (8 * 0) : (9 * 0);
+   bool touch = data[offset + 3]  0x80;
 
-   if (y ==  input-abs[ABS_Y])
-   y++;
+   /*
+* Touch events need to be disabled while stylus is
+* in proximity because user's hand is resting on touchpad
+* and sending unwanted events.  User expects tablet buttons
+* to continue working though.
+*/
+   touch = touch  !wacom-shared-stylus_in_proximity;
+
+   if (touch)
+   touch_count++;
+
+   /* Only 1st touch is supported in kernels without MT */
+   if (i  0)
+   continue;
+
+   if (touch) {
+   int x = get_unaligned_be16(data[offset + 3])  0x7ff;
+   int y

Re: [Linuxwacom-devel] Issues with DTI-520

[Chris Bagwell]

 DTI520UB/L: Applying InputClass Wacom class
 [196927.551] (II) Using input driver 'wacom' for 'Wacom DTI520UB/L'
 [196927.551] (II) Loading /usr/lib/xorg/modules/input/wacom_drv.so
 [196927.551] (**) Wacom DTI520UB/L: always reports core events
 [196927.551] (**) Option Device /dev/input/event14
 [196927.551] (II) Wacom DTI520UB/L: type not specified, assuming 'stylus'.
 [196927.551] (II) Wacom DTI520UB/L: other types will be automatically added.
 [196927.551] (--) Wacom DTI520UB/L stylus: using pressure threshold of 27 for 
 button 1
 [196927.551] (--) Wacom DTI520UB/L stylus: Wacom USB PL/Cintiq tablet 
 maxX=6282 maxY=4762 maxZ=511 resX=2 resY=2  tilt=disabled
 [196927.551] (II) Wacom DTI520UB/L stylus: hotplugging dependent devices.
 [196927.551] (EE) Wacom DTI520UB/L stylus: Invalid type 'eraser' for this 
 device.
 [196927.551] (EE) Wacom DTI520UB/L stylus: Invalid type 'cursor' for this 
 device.
 [196927.551] (EE) Wacom DTI520UB/L stylus: Invalid type 'touch' for this 
 device.
 [196927.551] (II) Wacom DTI520UB/L stylus: hotplugging completed.
 [196927.657] (**) Option config_info 
 udev:/sys/devices/pci:00/:00:1a.7/usb1/1-6/1-6.4/1-6.4:1.1/input/input103/event14
 [196927.657] (II) XINPUT: Adding extended input device Wacom DTI520UB/L 
 stylus (type: STYLUS, id 15)
 [196927.657] (**) Wacom DTI520UB/L stylus: (accel) keeping acceleration 
 scheme 1
 [196927.657] (**) Wacom DTI520UB/L stylus: (accel) acceleration profile 0
 [196927.657] (**) Wacom DTI520UB/L stylus: (accel) acceleration factor: 2.000
 [196927.657] (**) Wacom DTI520UB/L stylus: (accel) acceleration threshold: 4
 [196927.657] (**) Wacom DTI520UB/L pad: Applying InputClass Wacom class
 [196927.657] (**) Wacom DTI520UB/L pad: Applying InputClass evdev tablet 
 catchall
 [196927.657] (**) Wacom DTI520UB/L pad: Applying InputClass Wacom class
 [196927.657] (II) Using input driver 'wacom' for 'Wacom DTI520UB/L pad'
 [196927.657] (II) Loading /usr/lib/xorg/modules/input/wacom_drv.so
 [196927.657] (**) Wacom DTI520UB/L pad: always reports core events
 [196927.657] (**) Option Device /dev/input/event14
 [196927.657] (**) Option Type pad
 [196927.657] (--) Wacom DTI520UB/L pad: Wacom USB PL/Cintiq tablet maxX=6282 
 maxY=4762 maxZ=511 resX=2 resY=2  tilt=disabled
 [196927.710] (**) Option config_info 
 udev:/sys/devices/pci:00/:00:1a.7/usb1/1-6/1-6.4/1-6.4:1.1/input/input103/event14
 [196927.710] (II) XINPUT: Adding extended input device Wacom DTI520UB/L pad 
 (type: PAD, id 16)
 [196927.710] (**) Wacom DTI520UB/L pad: (accel) keeping acceleration scheme 1
 [196927.710] (**) Wacom DTI520UB/L pad: (accel) acceleration profile 0
 [196927.710] (**) Wacom DTI520UB/L pad: (accel) acceleration factor: 2.000
 [196927.710] (**) Wacom DTI520UB/L pad: (accel) acceleration threshold: 4

 Select the device event number [0-14]: 13
 Input driver version is 1.0.1
 Input device ID: bus 0x3 vendor 0x56a product 0x3a version 0x103
 Input device name: Wacom DTI520UB/L
 Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 256 (BTN_0)
    Event code 257 (BTN_1)
    Event code 258 (BTN_2)
    Event code 259 (BTN_3)
    Event code 260 (BTN_4)
    Event code 272 (BTN_LEFT)
    Event code 273 (BTN_RIGHT)
    Event code 276 (BTN_EXTRA)
    Event code 277 (BTN_FORWARD)
    Event code 278 (BTN_BACK)
    Event code 320 (BTN_TOOL_PEN)
    Event code 330 (BTN_TOUCH)
    Event code 331 (BTN_STYLUS)
    Event code 332 (BTN_STYLUS2)
  Event type 3 (EV_ABS)
    Event code 0 (ABS_X)
      Value      0
      Min        0
      Max     6282
      Fuzz       4
      Resolution      20
    Event code 1 (ABS_Y)
      Value      0
      Min        0
      Max     4762
      Fuzz       4
      Resolution      20
    Event code 24 (ABS_PRESSURE)
      Value      0
      Min        0
      Max      511
    Event code 40 (ABS_MISC)
      Value      0
      Min        0
      Max        0
 Testing ... (interrupt to exit)

 Let me know if any of this hints at anything.

It all looks pretty reasonable.  My one suggestion is in kernel
driver, comment out the part that declares ABS_MISC as a capability.
xf86-input-wacom treats that special and then I think requires an
MISC_SERIAL event to also be sent.

The other hint is to run 'xinput set-prop device_name Common Debug
Levels 10 10' then each event received will be logged to Xorg.0.log.

Chris


 Cheers,
 Adam.


--
Try before you buy = See our experts in action!
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-dev2
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH] HID: wacom: Force Wacom PTK-540WL name for Intuos4 WL

[Chris Bagwell]

On Mon, Feb 13, 2012 at 3:26 PM, Przemo Firszt prz...@firszt.eu wrote:
 Please comment if you're OK with the name or it should be rather Wacom
 Intuos4 WL or maybe something else.

Here is what I thinking.  You current code is geared that it can
easily be reused for new versions of HW as long as the continue to use
the Intous4 packet format.

The phrase Wacom PKT-540WL will only be valid value for a single HW
Product ID.  The phrase Wacom Intuos4 WL will be valid for multiple
HW Product ID's.

They are both good choices but I would use a table lookup if your
going to use per Product ID values or generic value if your going to
create it inline with other initialization.

Chris


 I hope it's safe to override the name in the way used...
 --
 Regards,
 Przemo


--
Try before you buy = See our experts in action!
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-dev2
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH] HID: wacom: Force Wacom PTK-540WL name for Intuos4 WL

[Chris Bagwell]

On Mon, Feb 13, 2012 at 3:20 PM, Przemo Firszt prz...@firszt.eu wrote:
 The name reported by Inutos4 WL connected by bluetooth is PTK-540WL and
 to make it consistent with other Wacom devices it has to be converted to
 Wacom PTK-540WL. It also makes userland applications aware that it's a Wacom
 device.

 Signed-off-by: Przemo Firszt prz...@firszt.eu
 ---
  drivers/hid/hid-wacom.c |    2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

 diff --git a/drivers/hid/hid-wacom.c b/drivers/hid/hid-wacom.c
 index acab74c..700aa8d 100644
 --- a/drivers/hid/hid-wacom.c
 +++ b/drivers/hid/hid-wacom.c
 @@ -471,6 +471,7 @@ static int wacom_input_mapped(struct hid_device *hdev, 
 struct hid_input *hi,
                input_set_abs_params(input, ABS_DISTANCE, 0, 32, 0, 0);
                break;
        case USB_DEVICE_ID_WACOM_INTUOS4_BLUETOOTH:
 +
                input_set_abs_params(input, ABS_X, 0, 40640, 4, 0);
                input_set_abs_params(input, ABS_Y, 0, 25400, 4, 0);
                input_set_abs_params(input, ABS_PRESSURE, 0, 2047, 0, 0);
 @@ -518,6 +519,7 @@ static int wacom_probe(struct hid_device *hdev,
                wacom_poke(hdev, 1);
                break;
        case USB_DEVICE_ID_WACOM_INTUOS4_BLUETOOTH:
 +               sprintf(hdev-name, %s, Wacom PTK-540WL);

Do you know where this memory is allocated and its size?  I've seen it
done this way before but I've never bothered to understand what is
being overwritten.

Please don't hold up submitting it on this comment though.

Chris

                wdata-features = 0;
                wacom_set_features(hdev);
                break;
 --
 1.7.6.4


--
Try before you buy = See our experts in action!
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-dev2
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] Issues with DTI-520

[Chris Bagwell]

On Sun, Feb 12, 2012 at 5:53 AM, Adam Nielsen a.niel...@shikadi.net wrote:
 Well, I seem to have had some success!

 Yes, that is all I mean.  Based on your later info, it means there
 would be some code that looks like this:

 if (packet_size == 8  data[0] == 2)
   // Do pen processing
 else if (packet_size == 6  data[0] == 4)
   // Do button processing.


 This worked quite well.  I do however get two identical devices appearing
 (both tablets with buttons) rather than one tablet and one set of buttons as
 I think would be more logical.  Not sure how to address this though.

Its wacom_setup_input_capabilities() job to declare and not declare
correct events for each interface.  Right now, all devices have an X/Y
so you'll have a new case of button only.

For temporary hack, I'd check for pktlen or interface # in that
function to hide what you need.  For other multi-interface cases, 1
interface is a stylus tablet and 1 interface is a touchpad so we 1st
set and then check device_type to see what events to hide.

We kinda need a new device type that says Pad-only.  Probably a fixed
value of 0 to mean !Pen and !Touch will be good enough for now.



 Agree.  Looks like 8 it is.  When 1 USB device has 2 interfaces, each
 interface can have a different packet length.  In Wacom driver, our
 convention is to put the pen's packet length in the table your
 modifying and then set at run time for the other interface.


 Is there an example of where this is set at runtime?  I used your example:


                if (intf-cur_altsetting-desc.bInterfaceNumber == 1) {


 And hacked it into wacom_sys.c which worked, but of course only on my PC
 with this one tablet.


Yes, check in wacom_parse_hid().  It looks for clues in HID report to
see what interface is and set both pktlen and device_type.  If it
finds no hints then it defaults to a pen device with what ever packet
size is set in structure.

I think this is first device I've seen with a System Control usage
so that could probably be used to detect the button interface and
override the pen/pktlen defaults.


 Thats all on stylus.  Sometimes they include extra info like max X/Y
 values and resolution but doesn't look like it in this report.  You'll
 have to figure those out at some point and fill them in structures.


 Done that, and it turns out they match exactly with the DTF521, which I
 guess isn't surprising for a model called DTI520.

:-)



 Interesting.  Your USB hub works a little different then mine with
 over specifying packet size to receive.  I think its related to
 needing 2 button presses for buttons.


 Yes, it seems that it waits until the buffer is full before returning data.
 Once I figured out the correct buffer sizes everything became very
 responsive.

 024008f5 002d
 aabb pppz


 Ok.  You've got what looks like new packet format.


 Many thanks for all your pointers!  I have now successfully gotten the
 device to report all its events in evtest.  The X and Y coordinates work
 fine, pressure seems to work too, and all of the buttons work - both the
 stylus buttons and the pushbuttons on the display surface!


I think this is a record for how fast someone has gotten a new device
with so many differences working!

 Surprisingly the X and Y values (and also the pressure) are in big-endian
 order.  Suddenly all the weird results I was getting before make a lot more
 sense!

  input_report_key(input, BTN_STYLUS, data[7]  0x01);
  input_report_key(input, BTN_STYLUS2, data[7]  0x02);
  input_report_abs(input, ABS_X, be16_to_cpup((__be16 *)data[2]));
  input_report_abs(input, ABS_Y, be16_to_cpup((__be16 *)data[4]));
  pressure = (data[6]  1) | ((data[7]  0x80)  7);
  if (pressure  0)
    pressure = features-pressure_max + pressure + 1;
  input_report_abs(input, ABS_PRESSURE, pressure);

 Unfortunately once I reached this point the X driver stopped working.  It
 detects the device but xinput test doesn't report any output.  I'm a bit
 stumped at this because I haven't changed anything in the X driver and the
 events are all being reported correctly by the kernel.

 Looking at the X output, it looks like it is reading the tablet interface as
 a pad (only looking for the buttons and there aren't any here) and reading
 the other interface as a tablet (where there is no tablet, only buttons.)  I
 can't see where this is set - any hints?  Maybe I need to better separate
 the two devices, and not report a button/tablet when there isn't one.


Can you send output from xinput list and snippet of your
/var/log/Xorg.0.log were each wacom input is detected?  It woud also
be helpful to see the initial output of evtest for your stylus device
where it prints out the supported capabilities.


 This says the 1st 5 bits in packet map to buttons and have on/off single
 values.

 Above has values between 6 and 10 so are more than 1 bit.  Not sure
 what it is but there are 3 of them.  And then 5 of something else and
 3 of another thing follows.


 Not sure how 

Re: [Linuxwacom-devel] Issues with DTI-520

[Chris Bagwell]

On Sat, Feb 11, 2012 at 2:21 AM, Adam Nielsen a.niel...@shikadi.net wrote:
 Hi all,

 I recently got hold of a second-hand DTI-520 and I'd like to get it working
 under Linux.  It seems it is not yet supported, so I am trying to add support
 for it.



 Some of the code I added to the kernel module is:

 static const struct wacom_features wacom_features_0x3A =
   { Wacom DTI520UB/L,     WACOM_PKGLEN_GRAPHIRE,   3250, 65600,  2047,
     0, PL, WACOM_PL_RES, WACOM_PL_RES };


Hi, I googled this model and I see its a stand alone screen with built
in Wacom digitizer.

I'm guessing you chose those initial values because there is a 0x39
already defined and modelled after it?  In general, that is a good
approach.  Wacom does tend to group related HW with similar product
ID's.

Here are some additional things you can try:

Run the following commands as root:

rmmod wacom
lsusb -vvv

Find the snippet related to Wacom and send it to list.  In that output
will often be information on packet sizes.  We can use this
information to know what value to set for WACOM_PKGLEN_* without
guessing.  Worst case, set that field to 32 for right now and move to
next step.

The part that has PL above is what tells packet format and there are
lots of different packet formats.  Hopefully, this is not a totally
new format.

Since PL and PTU didn't work for you, I'd move to some of the other
similar HW types (screens with digitizers).  Cintiq's are most popular
and possible values for those are WACOM_24HD, CINTIQ, WACOM_BEE, and
WACOM_21UX2.

Probably, your screen is closer to the DTU-* and DTF-* models that are
already supported.  DTU and PTU are valid values for it so I'd
probably try DTU next.

And the last option to try is Tablet PC driver.  They use TABLETPC.

If no luck with any of those, we'd have to start logging some USB
packets (using kernels /sys/kernel/debug/usb/usbmon interface) and see
if we can't figure out the packet format and add a new DTI driver.

Chris

--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] Intuos4 WL is handled by evdev - what's wrong?

[Chris Bagwell]

On Sat, Feb 11, 2012 at 7:52 AM, Peter Hutterer
peter.hutte...@who-t.net wrote:
 On Sat, Feb 11, 2012 at 11:24:15AM +, Przemo Firszt wrote:
 Wacom4 WL on usb cable - Wacom is part of the name, but ID_VENDOR
 field contains Tablet 8-):

 P: /devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0/input/input10
 E: UDEV_LOG=3
 E:
 DEVPATH=/devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0/input/input10
 E: PRODUCT=3/56a/bc/127
 E: NAME=Wacom Intuos4 WL
 E: PROP=1
 E: EV=1f
 E: KEY=1cdf 0 1f01ff 0 0 0 0 0 0 0 0
 E: REL=100
 E: ABS=100 f000167
 E: MSC=1
 E:
 MODALIAS=input:b0003v056Ap00BCe0127-e0,1,2,3,4,k100,101,102,103,104,105,106,107,108,110,111,112,113,114,140,141,142,143,144,146,147,14A,14B,14C,r8,a0,1,2,5,6,8,18,19,1A,1B,28,m0,lsfw
 E: SUBSYSTEM=input
 E: ID_INPUT=1
 E: ID_INPUT_TABLET=1
 E: ID_VENDOR=Tablet
 E: ID_VENDOR_ENC=Tablet
 E: ID_VENDOR_ID=056a
 E: ID_MODEL=PTK-540WL
 E: ID_MODEL_ENC=PTK-540WL
 E: ID_MODEL_ID=00bc
 E: ID_REVISION=0127
 E: ID_SERIAL=Tablet_PTK-540WL_00-10-60-26-58-e7
 E: ID_SERIAL_SHORT=00-10-60-26-58-e7
 E: ID_TYPE=hid
 E: ID_BUS=usb
 E: ID_USB_INTERFACES=:030102:
 E: ID_USB_INTERFACE_NUM=00
 E: ID_USB_DRIVER=wacom
 E: ID_PATH=pci-:00:1d.0-usb-0:1:1.0
 E: ID_PATH_TAG=pci-_00_1d_0-usb-0_1_1_0

 Some of the kernel drivers are cheanging device name, so we could
 possibly do the same. Example here:
 drivers/hid/hid-hyperv.c:       sprintf(hid_dev-name, %s, Microsoft
 Vmbus HID-compliant Mouse);

 but it's a workaround and I think it's not worth to do it.

 I think it's worth it. the ID_VENDOR_ID is 0x56a which is Wacom, the string
 should reflect this to make userspace simpler.

And adding this is aligned with wacom_sys.c.  It is doing same
dev-name update and why you see Wacom in your output:

E: NAME=Wacom Intuos4 WL


 Cheers,
  Peter

--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] Issues with DTI-520

[Chris Bagwell]

On Sat, Feb 11, 2012 at 6:23 PM, Adam Nielsen a.niel...@shikadi.net wrote:
 Hi Chris,

 Thanks for the quick response!


 Hi, I googled this model and I see its a stand alone screen with built
 in Wacom digitizer.


 Yes that's correct.  For the record, it also has a built in USB hub which
 works fine:

 Bus 001 Device 021: ID 056a:003b Wacom Co., Ltd
 Device Descriptor:
  ...
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         1 Single TT
  bMaxPacketSize0        64
  idVendor           0x056a Wacom Co., Ltd
  idProduct          0x003b
  bcdDevice            7.02
  iManufacturer          10 WACOM
  iProduct               11 DTI-520 HUB
  ...

 The device also has a number of pushbuttons on its face - five unlabelled
 ones across the top (with a space to insert your own paper label), and six
 along the bottom (L, R, up, down, and two Ctrl.  One Ctrl suggests it shifts
 the up/down keys into zoom in/out.)

Interesting.  I've never heard they did USB hubs before.

For the buttons, none of the wacom drivers currently support anything
quite like this.  I see in the USB report that the device has 2
interfaces.  Normally, we only see this on touchscreens where the
second interface reports touch events.

In your case, the second interface seems to define those buttons.  I
see a set of 5 buttons clearly labeled and then some more bits that
aren't obvious how to decode.

You'd have to write a custom decoder for those if you want to process
them.  In mean time, we may or may not need to detect that interface
and disable it (if it crashes for example).



 Here is the output:

 Bus 001 Device 022: ID 056a:003a Wacom Co., Ltd
 Device Descriptor:

...

This first section defines a mouse device.  Its default behaviour or
Wacom devices.  If it wasn't for the fact that all Wacom devices are
blacklisted from the hid-core, this screen would most likely already
be working but as an odd mouse (relative mode).

      iInterface              0
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.10
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength     110
          Report Descriptor: (length is 110)
            Item(Global): Usage Page, data= [ 0x01 ] 1
                            Generic Desktop Controls
            Item(Local ): Usage, data= [ 0x02 ] 2
                            Mouse
            Item(Main  ): Collection, data= [ 0x01 ] 1
                            Application
            Item(Global): Report ID, data= [ 0x01 ] 1
            Item(Local ): Usage, data= [ 0x01 ] 1
                            Pointer
            Item(Main  ): Collection, data= [ 0x00 ] 0
                            Physical
            Item(Global): Usage Page, data= [ 0x09 ] 9
                            Buttons
            Item(Local ): Usage Minimum, data= [ 0x01 ] 1
                            Button 1 (Primary)
            Item(Local ): Usage Maximum, data= [ 0x03 ] 3
                            Button 3 (Tertiary)
            Item(Global): Logical Minimum, data= [ 0x00 ] 0
            Item(Global): Logical Maximum, data= [ 0x01 ] 1
            Item(Global): Report Count, data= [ 0x03 ] 3
            Item(Global): Report Size, data= [ 0x01 ] 1
            Item(Main  ): Input, data= [ 0x02 ] 2
                            Data Variable Absolute No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile
 Bitfield
            Item(Global): Report Count, data= [ 0x05 ] 5
            Item(Main  ): Input, data= [ 0x03 ] 3
                            Constant Variable Absolute No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile
 Bitfield
            Item(Global): Usage Page, data= [ 0x01 ] 1
                            Generic Desktop Controls
            Item(Local ): Usage, data= [ 0x30 ] 48
                            Direction-X
            Item(Local ): Usage, data= [ 0x31 ] 49
                            Direction-Y
            Item(Global): Logical Minimum, data= [ 0x81 ] 129
            Item(Global): Logical Maximum, data= [ 0x7f ] 127
            Item(Global): Report Size, data= [ 0x08 ] 8
            Item(Global): Report Count, data= [ 0x02 ] 2
            Item(Main  ): Input, data= [ 0x06 ] 6
                            Data Variable Relative No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile
 Bitfield
            Item(Main  ): End Collection, data=none
            Item(Main  ): End Collection, data=none

This second defines the report id #2 that contains pen data:

            Item(Global): Usage Page, data= [ 0x0d ] 13
                            Digitizer
            Item(Local ): Usage, data= [ 0x01 ] 1
                            Digitizer
            Item(Main  ): Collection, data= [ 0x01 ] 1

Re: [Linuxwacom-devel] Issues with DTI-520

[Chris Bagwell]

On Sat, Feb 11, 2012 at 8:42 PM, Adam Nielsen a.niel...@shikadi.net wrote:
 For the buttons, none of the wacom drivers currently support anything
 quite like this.  I see in the USB report that the device has 2
 interfaces.  Normally, we only see this on touchscreens where the
 second interface reports touch events.

 In your case, the second interface seems to define those buttons.  I
 see a set of 5 buttons clearly labeled and then some more bits that
 aren't obvious how to decode.

 You'd have to write a custom decoder for those if you want to process
 them.  In mean time, we may or may not need to detect that interface
 and disable it (if it crashes for example).


 When you say 'custom decoder' does that mean just figuring out the protocol,
 and using existing code for reporting button presses?  Or will it require
 adding support for buttons from scratch?

Yes, that is all I mean.  Based on your later info, it means there
would be some code that looks like this:

if (packet_size == 8  data[0] == 2)
  // Do pen processing
else if (packet_size == 6  data[0] == 4)
  // Do button processing.

Thats all. Not to bad, coding wise.



 This says the packet size is 7 8-bit bytes.  That maps to
 WACOM_PKGLEN_PENPRTN.  I've seen occasionally where they do not
 include in this count the 1st byte in packet which is ID.  So the
 packet len could either be 7 or 8.  I'd try 8 first which maps to
 WACOM_PKGLEN_GRAPHIRE.


 As per below, it looks like this is 8.

Agree.  Looks like 8 it is.  When 1 USB device has 2 interfaces, each
interface can have a different packet length.  In Wacom driver, our
convention is to put the pen's packet length in the table your
modifying and then set at run time for the other interface.



 Thats all on stylus.  Sometimes they include extra info like max X/Y
 values and resolution but doesn't look like it in this report.  You'll
 have to figure those out at some point and fill them in structures.


 That's fine.  Am I looking at e.g. usbmon to find out the maximum value or
 xinput output, evtest, or somewhere else?

evtest is my preferred for max X/Y.  Just need to draw at borders of
screen and see max values reported.  Resolution is manually computed
based on screen size to max X/Y... but in kernel its stored in metric
and screen size is often in inches so you'll need to convert.
Usually, its some round number like 100 to help you know when you got
it right.



 Its kinda a max packet length.  With most peoples USB hubs, its OK to
 leave it large.  Some USB hubs will return an error if a packet is
 received with less bytes then requested and on those machines you have
 to get this value exactly right.


 Ah, that explains a few things from other USB tinkering I've done...  The
 behaviour hasn't changed with a packet length of 32, so looks like that's
 ok.


 All the stylus formats are usually pretty similar but it takes just 1
 bit in a different location and it will act totally strange.


 That probably explains the wrapping around of the Y coordinate with PL and
 PTU then.


 Since PL and PTU didn't work for you, I'd move to some of the other
 similar HW types (screens with digitizers).  Cintiq's are most popular
 and possible values for those are WACOM_24HD, CINTIQ, WACOM_BEE, and
 WACOM_21UX2.


 Is WACOM_24HD new?  It's not in the code I have.  Otherwise here are my
 results:

Yes, very new.  It will be in Linux 3.3 I think.


 CINTIQ: X crash
 WACOM_BEE: X crash
 WACOM_21UX2: no events, long time to load module, errors about no device
 'pad'
 DTU: no events


 I didn't try DTU because in wacom_setup_input_capabilities() in the
 kernel
 driver it seems to be handled the same as PL.  Is it treated differently
 elsewhere?


 Yes, there is a wacom_dtu_irq() and the stylus bits are every so
 slightly different.


 Ah, will have to look at that.  At any rate PTU definitely works better than
 DTU.


 And the last option to try is Tablet PC driver.  They use TABLETPC.


 No luck - no events returned.


 If no luck with any of those, we'd have to start logging some USB
 packets (using kernels /sys/kernel/debug/usb/usbmon interface) and see
 if we can't figure out the packet format and add a new DTI driver.


 Here is some usbmon output for the device:

 C Ii:025:01 0 32 = 0240177a 0cee 02401780 0ce6 02401784 0ce7
 02401789 0ce3
 S Ii:025:01 -115 32 

 If the data is in bytes, then it seems to be eight bytes repeated up to the
 32-byte buffer length.  If I change the buffer length back to 8 I seem to
 get a bunch of clean events:

 880229ce40c0 304567392 C Ii:025:01 0 8 = 024008f5 002d
 880229ce40c0 304567405 S Ii:025:01 -115 8 

Interesting.  Your USB hub works a little different then mine with
over specifying packet size to receive.  I think its related to
needing 2 button presses for buttons.


 Taking just the data and examining it:

 024008f5 002d
 aabb pppz

 x and y are absolute coordinates, p is pressure (0 to ff80).  It looks like
 this is 

Re: [Linuxwacom-devel] Intuos4 WL is handled by evdev - what's wrong?

[Chris Bagwell]

On Fri, Feb 10, 2012 at 11:54 AM, Przemo Firszt prz...@firszt.eu wrote:
 Dnia 2012-02-11, sob o godzinie 03:27 +1000, Peter Hutterer pisze:
 On Fri, Feb 10, 2012 at 04:56:11PM +, Przemo Firszt wrote:
  I was trying to find out why xsetwacom --list devices shows nothing
  and I found that my tablet is being handled by evdev.
  Details here: http://pastebin.com/jASCqiKC
 
  I can't see any blacklisted devices list in evdev, so I could exclude
  it nor I can see anything wrong in xorg driver for wacom (it's the same
  as for Graphire4 Bluetooth and for that one xsetwacom worked).
 
  Any ideas where to look for solution?

 /usr/share/X11/xorg.conf/d/50-wacom.conf on my machine matches mainly
 against Wacom in the product name - that's missing on this device. Try
 using MatchVendor, provided that contains a string that's matchable.
 If so, pls let us know so we can update the .conf file.

 Hi Peter,
 Spot on, 10/10, bull's-eye and the main prize :-)

 [przemo@pldmachine ~]$ head /usr/share/X11/xorg.conf.d/50-wacom.conf
 Section InputClass
       Identifier Wacom class
       MatchProduct Wacom|WACOM|WALTOP|Hanwang|PTK-540WL
       MatchDevicePath /dev/input/event*
       Driver wacom
 EndSection

 Section InputClass
       Identifier Wacom serial class
       MatchProduct Serial Wacom Tablet

 I added PTK-540WL to MatchProduct. I'm not sure if that's the best way, but 
 it's
 hard to decide without knowing how other wacom devices are called.
 Patch on the way in a next 5 minutes.

 Thanks!! :-)

It would be better to have a new rule that matches Vendor name.

Section InputClass
  Identifier Wacom Vendor class
  MatchVendor Wacom
  MatchDevicePath /dev/input/event*
  Driver wacom
EndSection

For wacom USB kernel driver, the phrase Wacom is hard coded into
Product name in by driver and it ignores the Product field from HW.
If it came purely from USB,  it would look just like your seeing.  For
example, the Product value in USB Device Descriptor for my Bamboo
shows CTH-670.

For wacom_w801 serial touchscreen driver, Wacom is also hard
coding Product name in driver.

hid-wacom is doing the reasonable thing of letting the base HID logic
set the Vendor and Product values from HID report.

I think its safe to assume Vendor will always be Wacom Co., Ltd for
Wacoms since there are little options on were to get that info from
but that Product name may or may not contain phrase Wacom.

Chris

--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH] Add Wacom Intuos4 Wireless to 50-wacom.conf

[Chris Bagwell]

On Fri, Feb 10, 2012 at 12:27 PM, Peter Hutterer
peter.hutte...@who-t.net wrote:
 On Fri, Feb 10, 2012 at 05:55:16PM +, Przemo Firszt wrote:
 Intuos4 Wireless doesn't match list of devices in 50-wacom.conf, so evdev was
 taking over. This patch fixes it, so now wacom driver is used fo Intuoe4 WL
 PTK-540WL

 Signed-off-by: Przemo Firszt prz...@firszt.eu

 out of interest - did MatchVendor work at all?

Przemo, if you want the inside scope of what it checks, run edevadm
info --export-db and look for area that defines your
/dev/input/event*.  The line with NAME=PTK-540WL is where the Product
Name came from and the the line ID_VENDOR=xxx is were I believe
MatchVendor gets its value.

Chris


 Cheers,
  Peter

 ---
  conf/50-wacom.conf |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/conf/50-wacom.conf b/conf/50-wacom.conf
 index 2c9ccb6..5cf5fdf 100644
 --- a/conf/50-wacom.conf
 +++ b/conf/50-wacom.conf
 @@ -1,6 +1,6 @@
  Section InputClass
       Identifier Wacom class
 -     MatchProduct Wacom|WACOM|WALTOP|Hanwang
 +     MatchProduct Wacom|WACOM|WALTOP|Hanwang|PTK-540WL
       MatchDevicePath /dev/input/event*
       Driver wacom
  EndSection
 --
 1.7.6.4


 --
 Virtualization  Cloud Management Using Capacity Planning
 Cloud computing makes use of virtualization - but cloud computing
 also focuses on allowing computing to be delivered as a service.
 http://www.accelacomm.com/jaw/sfnl/114/51521223/
 ___
 Linuxwacom-devel mailing list
 Linuxwacom-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH] Add Wacom Intuos4 Wireless to 50-wacom.conf

[Chris Bagwell]

On Fri, Feb 10, 2012 at 1:11 PM, Przemo Firszt prz...@firszt.eu wrote:
 Dnia 2012-02-10, pią o godzinie 12:44 -0600, Chris Bagwell pisze:
 On Fri, Feb 10, 2012 at 12:27 PM, Peter Hutterer
 peter.hutte...@who-t.net wrote:
  On Fri, Feb 10, 2012 at 05:55:16PM +, Przemo Firszt wrote:
  Intuos4 Wireless doesn't match list of devices in 50-wacom.conf, so evdev 
  was
  taking over. This patch fixes it, so now wacom driver is used fo Intuoe4 
  WL
  PTK-540WL
 
  Signed-off-by: Przemo Firszt prz...@firszt.eu
 
  out of interest - did MatchVendor work at all?

 Przemo, if you want the inside scope of what it checks, run edevadm
 info --export-db and look for area that defines your
 /dev/input/event*.  The line with NAME=PTK-540WL is where the Product
 Name came from and the the line ID_VENDOR=xxx is were I believe
 MatchVendor gets its value.


 Peter, Chris,
 I didn't tested it as I didn't see anything with vendor  after
 udevadm info --export-db. This is with PTK-540WL added, but (as far
 as I understand how it works) it makes no difference:

Based on your output below, yeah, I don't think it would work either.


 P: 
 /devices/pci:00/:00:1d.0/usb2/2-2/2-2:1.0/bluetooth/hci0/hci0:1/0005:056A:00BD.0002
 E: UDEV_LOG=3
 E:
 DEVPATH=/devices/pci:00/:00:1d.0/usb2/2-2/2-2:1.0/bluetooth/hci0/hci0:1/0005:056A:00BD.0002
 E: DRIVER=wacom
 E: HID_ID=0005:056A:00BD
 E: HID_NAME=PTK-540WL
 E: HID_PHYS=00:11:67:D6:1D:BF
 E: HID_UNIQ=00:10:60:26:58:E7
 E: MODALIAS=hid:b0005v056Ap00BD
 E: SUBSYSTEM=hid

 Other devices are reporting ID_VENDOR:

 [przemo@pldmachine ~]$ udevadm info  --export-db| grep ID_VENDOR
 E: ID_VENDOR_FROM_DATABASE=Broadcom Corporation
 E: ID_VENDOR_ID=0x14e4
 E: ID_VENDOR=ISSC
 E: ID_VENDOR_ENC=ISSC
 [..]

 Is it something that is worth investigation/fixing or I should just move
 on?

I don't know enough about Bluetooth and HID behavior to know why it
doesn't return an vendor ID.  The 0x56a is listed multiple times but
not always in a concatenated ID form.

So I'm not sure what else to investigate.

Chris

--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
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

[Chris Bagwell]

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] [PATCH] HID: wacom: Exclude battery reporting for Intuos4 WL

[Chris Bagwell]

On Sun, Feb 5, 2012 at 8:08 AM, Przemo Firszt prz...@firszt.eu wrote:
 Dnia 2012-02-04, sob o godzinie 10:52 -0600, Chris Bagwell pisze:
 Chris,
 irst of all - thanks for your comments!
 I've been monitoring battery topics lately (no pun intended :-) )
 because I'm adding adding similar logic to wacom_wac for wireless.  I
 know that the function power_supply_powers() that is in stack trace is
 brand new (not in official kernel) and associates a power supply to a
 specific device (nice so GUI's don't think our wacom's are powering
 our machines).

 It is in the mainline now [1]

 So I would suspect that feature first.  Can you try deleting the two
 calls to that function and see if crash goes away?

 I'm trying to figure out if theat's correct that Jeremy added twice the
 same call: power_supply_powers(wdata-battery, hdev-dev); instead of:
        power_supply_powers(wdata-battery, hdev-dev);
  and
        power_supply_powers(wdata-ac, hdev-dev);
 It might be the reason - compiling now...

Yeah, that could be issue as well.  If I recall correctly, registering
the same sysfs file name or directory twice will cause crashes like
this.

Since that topic came up, I thought I'd bring up a related item.  I
notice that hid-wacom is installing wacom_battery and wacom_ac.
hid-wiimote is only other example input I could find with battery and
its registering wiimote_battery.

Since bluetooth is designs to support concurrent devices, I would
think this could lead to crashes in the off case that user has
multiple tablets.  Although 2 Wacom's may not be typical, I would
think 2 wiimotes would be.

We might should be putting a # on ends of those names like most other areas do.

Chris


 I peeked in jikos's hid tree and the function looks like it registers
 a sysfs directory called powers.  I suspect its meant to be under
 the wacom_battery directory and thus the call needs to be moved
 *after* registering the battery device.

 I'll test that as well.

 This looks needed even for graphire's to work.

 Anyone with Graphire to test it?

 [1] http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%
 2Flinux.gita=searchh=HEADst=greps=power_supply_powers


--
Try before you buy = See our experts in action!
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-dev2
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH] HID: wacom: Exclude battery reporting for Intuos4 WL

[Chris Bagwell]

I've been monitoring battery topics lately (no pun intended :-) )
because I'm adding adding similar logic to wacom_wac for wireless.  I
know that the function power_supply_powers() that is in stack trace is
brand new (not in official kernel) and associates a power supply to a
specific device (nice so GUI's don't think our wacom's are powering
our machines).

So I would suspect that feature first.  Can you try deleting the two
calls to that function and see if crash goes away?

I peeked in jikos's hid tree and the function looks like it registers
a sysfs directory called powers.  I suspect its meant to be under
the wacom_battery directory and thus the call needs to be moved
*after* registering the battery device.

This looks needed even for graphire's to work.

Chris

On Sat, Feb 4, 2012 at 6:33 AM, Przemo Firszt prz...@firszt.eu wrote:
 Some words of explanation: when I was submitting the original patch for
 Intuos4 WL (78761ff9bc4e944e0b4e5df1e7eedcfdbb1a9a1a) there were no
 problems with connection, battery values were incorrect, but it was a
 minor issue. When the patch reached the mainline kernel it became
 unusable (crash report below). I tried to bisect the problem, but I
 failed. Guessing mode on The problem might be related to the attempt
 to send a packet to the tablet while the link is not yet established.
 I don't feel confident enough with kernel locks to suggest a solution
 yet, but I'm working on it.
 Currently I just switched off the sysfs code for I4WL in the driver. My
 only concern is that I don't have access to Graphire Bluetooth and there
 is a chance that the tablet might be affected as well..

 regards,
 Przemo

 Crash report (also here: http://pastebin.com/ZVNZWaPs) :

 Feb  1 21:47:58 pldmachine kernel: [   89.535952] Bluetooth: HIDP (Human 
 Interface Emulation) ver 1.2
 Feb  1 21:49:51 pldmachine kernel: [  202.347235] wacom 0005:056A:00BD.0001: 
 unknown main item tag 0x0
 Feb  1 21:49:51 pldmachine kernel: [  202.347999] input: PTK-540WL as 
 /devices/pci:00/:00:1d.0/usb2/2-2/2-2:1.0/blue
 tooth/hci0/hci0:1/input8
 Feb  1 21:49:51 pldmachine kernel: [  202.348201] wacom 0005:056A:00BD.0001: 
 input,hidraw0: BLUETOOTH HID v1.06 Mouse [PTK-5
 40WL] on 00:11:67:D6:1D:BF
 Feb  1 21:49:51 pldmachine kernel: [  202.416811] BUG: unable to handle 
 kernel NULL pointer dereference at 0020
 Feb  1 21:49:51 pldmachine kernel: [  202.416888] IP: [c1142bb4] 
 sysfs_do_create_link+0x24/0x1c0
 Feb  1 21:49:51 pldmachine kernel: [  202.416945] *pde = 
 Feb  1 21:49:51 pldmachine kernel: [  202.416973] Oops:  [#1]
 Feb  1 21:49:51 pldmachine kernel: [  202.417002] Modules linked in: 
 hid_wacom(+) hidp binfmt_misc rfcomm bnep cn i915 drm_k
 ms_helper drm i2c_algo_bit cfbfillrect cfbcopyarea cfbimgblt rtl8192cu 
 rtl8192c_common rtlwifi mac80211 ipw2200 libipw cfg80
 211 snd_intel8x0 snd_ac97_codec ac97_bus btusb bluetooth pcmcia snd_pcm 
 snd_timer snd rfkill intel_agp sdhci_pci intel_gtt v
 ideo yenta_socket tpm_infineon sdhci lib80211 soundcore evdev pcspkr 
 snd_page_alloc psmouse pcmcia_rsrc pcmcia_core backligh
 t mmc_core agpgart tg3 sg ohci_hcd uhci_hcd ehci_hcd usbhid usbcore 
 usb_common hid ata_piix libata sd_mod crc_t10dif scsi_mod ext4 crc16 mbcache 
 jbd2 jbd [last unloaded: scsi_wait_scan]
 Feb  1 21:49:51 pldmachine kernel: [  202.417660]
 Feb  1 21:49:51 pldmachine kernel: [  202.417676] Pid: 3759, comm: modprobe 
 Not tainted 3.3.0-rc1-2-1-g326ff11 #18 Hewlett-Packard HP Compaq nc4200 
 (PV983AW#ABU)  /0938
 Feb  1 21:49:51 pldmachine kernel: [  202.417781] EIP: 0060:[c1142bb4] 
 EFLAGS: 00010202 CPU: 0
 Feb  1 21:49:51 pldmachine kernel: [  202.417826] EIP is at 
 sysfs_do_create_link+0x24/0x1c0
 Feb  1 21:49:51 pldmachine kernel: [  202.417866] EAX: 0008 EBX: 
 0246 ECX: c1484021 EDX: e7624c68
 Feb  1 21:49:51 pldmachine kernel: [  202.417914] ESI: c1484021 EDI: 
 ef36bf00 EBP: ef307db8 ESP: ef307d80
 Feb  1 21:49:51 pldmachine kernel: [  202.417962]  DS: 007b ES: 007b FS: 
  GS: 00e0 SS: 0068
 Feb  1 21:49:51 pldmachine kernel: [  202.418005] Process modprobe (pid: 
 3759, ti=ef306000 task=e7560380 task.ti=ef306000)
 Feb  1 21:49:51 pldmachine kernel: [  202.418066] Stack:
 Feb  1 21:49:51 pldmachine kernel: [  202.418084]  0002 0001 
 ef307d90 c1383f88 ef307dcc f81037fa  e7624c68
 Feb  1 21:49:51 pldmachine kernel: [  202.418170]  e7693aa0 e7560380 
 e7693abc 0246 e7624000 ef36bf00 ef307dc4 c1142d62
 Feb  1 21:49:51 pldmachine kernel: [  202.418255]  0001 ef307dcc 
 c1289ed6 ef307df8 f812f5c0 0002 ef307df8 f8130028
 Feb  1 21:49:51 pldmachine kernel: [  202.418341] Call Trace:
 Feb  1 21:49:51 pldmachine kernel: [  202.418366]  [c1383f88] ? 
 mutex_unlock+0x8/0x10
 Feb  1 21:49:51 pldmachine kernel: [  202.418406]  [f81037fa] ? 
 hidp_output_raw_report+0x15a/0x1c0 [hidp]
 Feb  1 21:49:51 pldmachine kernel: [  202.418457]  [c1142d62] 
 sysfs_create_link+0x12/0x20
 Feb  1 21:49:51 pldmachine kernel

Re: [Linuxwacom-devel] [PATCH] Move some usb-specific keys to wcmUSBData.

[Chris Bagwell]

And today I'm less dizzy.  Thanks!

Reviewed-by: Chris Bagwell ch...@cnpbagwell.com


On Sat, Feb 4, 2012 at 3:23 AM, Peter Hutterer peter.hutte...@who-t.net wrote:
 nbuttons and npadkeys is only used for USB-specific parsing, move them
 there.

 Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
 ---
 No functional change

  src/wcmUSB.c        |   29 ++---
  src/xf86WacomDefs.h |    4 
  2 files changed, 18 insertions(+), 15 deletions(-)

 diff --git a/src/wcmUSB.c b/src/wcmUSB.c
 index 8451c25..a2d30da 100644
 --- a/src/wcmUSB.c
 +++ b/src/wcmUSB.c
 @@ -40,6 +40,9 @@ typedef struct {
        int wcmPrevChannel;
        int wcmEventCnt;
        struct input_event wcmEvents[MAX_USB_EVENTS];
 +       int nbuttons;                /* total number of buttons */
 +       int npadkeys;                /* number of pad keys in the above array 
 */
 +       int padkey_code[WCM_MAX_BUTTONS];/* hardware codes for buttons */
  } wcmUSBData;

  static Bool usbDetect(InputInfoPtr);
 @@ -320,6 +323,7 @@ static Bool usbWcmInit(InputInfoPtr pInfo, char* id, 
 float *version)
        struct input_id sID;
        WacomDevicePtr priv = (WacomDevicePtr)pInfo-private;
        WacomCommonPtr common = priv-common;
 +       wcmUSBData *usbdata;

        DBG(1, priv, initializing USB tablet\n);

 @@ -331,6 +335,7 @@ static Bool usbWcmInit(InputInfoPtr pInfo, char* id, 
 float *version)
                return !Success;
        }

 +       usbdata = common-private;
        *version = 0.0;

        /* fetch vendor, product, and model name */
 @@ -355,10 +360,10 @@ static Bool usbWcmInit(InputInfoPtr pInfo, char* id, 
 float *version)
        }

        /* Find out supported button codes. */
 -       common-npadkeys = 0;
 +       usbdata-npadkeys = 0;
        for (i = 0; i  ARRAY_SIZE(padkey_codes); i++)
                if (ISBITSET (common-wcmKeys, padkey_codes [i]))
 -                       common-padkey_code [common-npadkeys++] = 
 padkey_codes [i];
 +                       usbdata-padkey_code [usbdata-npadkeys++] = 
 padkey_codes [i];

        if (!(ISBITSET (common-wcmKeys, BTN_TOOL_MOUSE)))
        {
 @@ -372,8 +377,8 @@ static Bool usbWcmInit(InputInfoPtr pInfo, char* id, 
 float *version)
                /* Make sure room for fixed map mouse buttons.  This
                 * means mappings may overlap with padkey_codes[].
                 */
 -               if (i != 0  common-npadkeys  WCM_USB_MAX_MOUSE_BUTTONS)
 -                       common-npadkeys = WCM_USB_MAX_MOUSE_BUTTONS;
 +               if (i != 0  usbdata-npadkeys  WCM_USB_MAX_MOUSE_BUTTONS)
 +                       usbdata-npadkeys = WCM_USB_MAX_MOUSE_BUTTONS;
        }

        /* nbuttons tracks maximum buttons on all tools (stylus/mouse).
 @@ -382,9 +387,9 @@ static Bool usbWcmInit(InputInfoPtr pInfo, char* id, 
 float *version)
         * Stylus support tip and 2 stlyus buttons.
         */
        if (ISBITSET (common-wcmKeys, BTN_TOOL_MOUSE))
 -               common-nbuttons = WCM_USB_MAX_MOUSE_BUTTONS;
 +               usbdata-nbuttons = WCM_USB_MAX_MOUSE_BUTTONS;
        else
 -               common-nbuttons = WCM_USB_MAX_STYLUS_BUTTONS;
 +               usbdata-nbuttons = WCM_USB_MAX_STYLUS_BUTTONS;

        return Success;
  }
 @@ -600,12 +605,13 @@ static int usbDetectConfig(InputInfoPtr pInfo)
  {
        WacomDevicePtr priv = (WacomDevicePtr)pInfo-private;
        WacomCommonPtr common = priv-common;
 +       wcmUSBData *usbdata = common-private;

        DBG(10, common, \n);
        if (IsPad (priv))
 -               priv-nbuttons = common-npadkeys;
 +               priv-nbuttons = usbdata-npadkeys;
        else
 -               priv-nbuttons = common-nbuttons;
 +               priv-nbuttons = usbdata-nbuttons;

        if (!common-wcmCursorProxoutDist)
                common-wcmCursorProxoutDist
 @@ -1303,6 +1309,7 @@ static int usbParseBTNEvent(WacomCommonPtr common,
  {
        int nkeys;
        int change = 1;
 +       wcmUSBData *usbdata = common-private;

        switch (event-code)
        {
 @@ -1329,15 +1336,15 @@ static int usbParseBTNEvent(WacomCommonPtr common,
                        break;

                default:
 -                       for (nkeys = 0; nkeys  common-npadkeys; nkeys++)
 +                       for (nkeys = 0; nkeys  usbdata-npadkeys; nkeys++)
                        {
 -                               if (event-code == common-padkey_code[nkeys])
 +                               if (event-code == 
 usbdata-padkey_code[nkeys])
                                {
                                        ds-buttons = mod_buttons(ds-buttons, 
 nkeys, event-value);
                                        break;
                                }
                        }
 -                       if (nkeys = common-npadkeys)
 +                       if (nkeys = usbdata-npadkeys)
                                change = 0;
        }
        return change;
 diff --git a/src/xf86WacomDefs.h b/src

Re: [Linuxwacom-devel] [PATCH] Initialize button action properties for the correct button number (#45557)

[Chris Bagwell]

It makes me dizzy trying to remember differences between
common-nbuttons, priv-nbuttons, and common-npadkeys.

This is definitely the direction we want to be moving and I'm 99% sure
there are no issues in this patch.  I reserve that 1% in case it
crashes and burns. :)

For both patches:

Reviewed-by: Chris Bagwell ch...@cnpbagwell.com

On Fri, Feb 3, 2012 at 3:31 AM, Peter Hutterer peter.hutte...@who-t.net wrote:
 Previous code had the number of properties for button actions hardcoded to
 16 (WCM_MAX_MOUSE_BUTTONS). Drop that define and instead initialize the same
 number of properties that we have on the device as well.

 X.Org Bug 45557 http://bugs.freedesktop.org/show_bug.cgi?id=45557

 Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
 ---
  src/wcmXCommand.c   |   29 -
  src/xf86WacomDefs.h |    7 +--
  2 files changed, 17 insertions(+), 19 deletions(-)

 diff --git a/src/wcmXCommand.c b/src/wcmXCommand.c
 index 6613a59..d0963f1 100644
 --- a/src/wcmXCommand.c
 +++ b/src/wcmXCommand.c
 @@ -122,9 +122,9 @@ static Atom InitWcmAtom(DeviceIntPtr dev, char *name, 
 Atom type, int format, int
  {
        int i;
        Atom atom;
 -       uint8_t val_8[WCM_MAX_MOUSE_BUTTONS];
 -       uint16_t val_16[WCM_MAX_MOUSE_BUTTONS];
 -       uint32_t val_32[WCM_MAX_MOUSE_BUTTONS];
 +       uint8_t val_8[WCM_MAX_BUTTONS];
 +       uint16_t val_16[WCM_MAX_BUTTONS];
 +       uint32_t val_32[WCM_MAX_BUTTONS];
        pointer converted = val_32;

        for (i = 0; i  nvalues; i++)
 @@ -156,7 +156,8 @@ void InitWcmDeviceProperties(InputInfoPtr pInfo)
  {
        WacomDevicePtr priv = (WacomDevicePtr) pInfo-private;
        WacomCommonPtr common = priv-common;
 -       int values[WCM_MAX_MOUSE_BUTTONS];
 +       int values[WCM_MAX_BUTTONS];
 +       int nbuttons;

        DBG(10, priv, \n);

 @@ -225,9 +226,11 @@ void InitWcmDeviceProperties(InputInfoPtr pInfo)
        values[0] = MakeAtom(pInfo-type_name, strlen(pInfo-type_name), TRUE);
        prop_tooltype = InitWcmAtom(pInfo-dev, WACOM_PROP_TOOL_TYPE, XA_ATOM, 
 32, 1, values);

 +
        /* default to no actions */
 +       nbuttons = min(max(priv-nbuttons + 4, 7), WCM_MAX_BUTTONS);
        memset(values, 0, sizeof(values));
 -       prop_btnactions = InitWcmAtom(pInfo-dev, WACOM_PROP_BUTTON_ACTIONS, 
 XA_ATOM, 32, WCM_MAX_MOUSE_BUTTONS, values);
 +       prop_btnactions = InitWcmAtom(pInfo-dev, WACOM_PROP_BUTTON_ACTIONS, 
 XA_ATOM, 32, nbuttons, values);

        if (IsPad(priv)) {
                memset(values, 0, sizeof(values));
 @@ -288,7 +291,7 @@ static int wcmSanityCheckProperty(XIPropertyValuePtr prop)
                        case AC_KEY:
                                break;
                        case AC_BUTTON:
 -                               if (code  WCM_MAX_MOUSE_BUTTONS)
 +                               if (code  WCM_MAX_BUTTONS)
                                        return BadValue;
                                break;
                        case AC_DISPLAYTOGGLE:
 @@ -492,12 +495,12 @@ static int wcmSetWheelOrStripProperty(DeviceIntPtr dev, 
 Atom property,
        switch (prop-format)
        {
                case 8:
 -                       if (values.v8[0]  WCM_MAX_MOUSE_BUTTONS ||
 -                           values.v8[1]  WCM_MAX_MOUSE_BUTTONS ||
 -                           values.v8[2]  WCM_MAX_MOUSE_BUTTONS ||
 -                           values.v8[3]  WCM_MAX_MOUSE_BUTTONS ||
 -                           values.v8[4]  WCM_MAX_MOUSE_BUTTONS ||
 -                           values.v8[5]  WCM_MAX_MOUSE_BUTTONS)
 +                       if (values.v8[0]  WCM_MAX_BUTTONS ||
 +                           values.v8[1]  WCM_MAX_BUTTONS ||
 +                           values.v8[2]  WCM_MAX_BUTTONS ||
 +                           values.v8[3]  WCM_MAX_BUTTONS ||
 +                           values.v8[4]  WCM_MAX_BUTTONS ||
 +                           values.v8[5]  WCM_MAX_BUTTONS)
                                return BadValue;

                        if (!checkonly) {
 @@ -846,7 +849,7 @@ int wcmSetProperty(DeviceIntPtr dev, Atom property, 
 XIPropertyValuePtr prop,
  #endif
        } else if (property == prop_btnactions)
        {
 -               if (prop-size != WCM_MAX_MOUSE_BUTTONS)
 +               if (prop-size != WCM_MAX_BUTTONS)
                        return BadMatch;
                wcmSetPropertyButtonActions(dev, property, prop, checkonly);
        } else
 diff --git a/src/xf86WacomDefs.h b/src/xf86WacomDefs.h
 index 3b79189..167866a 100644
 --- a/src/xf86WacomDefs.h
 +++ b/src/xf86WacomDefs.h
 @@ -188,12 +188,7 @@ struct _WacomModel
  #define DEFAULT_THRESHOLD (FILTER_PRESSURE_RES / 75)

  #define WCM_MAX_BUTTONS                32      /* maximum number of tablet 
 buttons */
 -#define WCM_MAX_MOUSE_BUTTONS  16      /* maximum number of 
 buttons-on-pointer
 -                                         * (which are treated as mouse 
 buttons

Re: [Linuxwacom-devel] [PATCH] hid-wacom: add support to Intuos4 pad buttons and dial

[Chris Bagwell]

Hi Aristeu,

I'm sure people will be happy to see this patch.  I've a question for you below.

On Wed, Feb 1, 2012 at 11:23 AM, Aristeu Rozanski a...@redhat.com wrote:
 This patch adds support for the pad buttons and dial in the bluetooth version
 of Intuos4.

 Signed-off-by: Aristeu Rozanski a...@redhat.com

 ---
  drivers/hid/hid-wacom.c |   38 ++
  1 file changed, 38 insertions(+)

 --- linus-2.6.orig/drivers/hid/hid-wacom.c      2012-02-01 11:54:09.0 
 -0500
 +++ linus-2.6/drivers/hid/hid-wacom.c   2012-02-01 12:17:46.166583951 -0500
 @@ -363,6 +363,35 @@            input_report_key(input, BTN_STYLUS2, d
        return;
  }

 +static void wacom_i4_parse_pad_report(struct wacom_data *wdata,
 +                       struct input_dev *input, unsigned char *data)
 +{
 +       input_report_key(input, BTN_0, (data[2]  0x01));
 +       input_report_key(input, BTN_1, (data[3]  0x01));
 +       input_report_key(input, BTN_2, (data[3]  0x02));
 +       input_report_key(input, BTN_3, (data[3]  0x04));
 +       input_report_key(input, BTN_4, (data[3]  0x08));
 +       input_report_key(input, BTN_5, (data[3]  0x10));
 +       input_report_key(input, BTN_6, (data[3]  0x20));
 +       input_report_key(input, BTN_7, (data[3]  0x40));
 +       input_report_key(input, BTN_8, (data[3]  0x80));
 +
 +       if (data[1]  0x80)
 +               input_report_abs(input, ABS_WHEEL, (data[1]  0x7f));
 +       else
 +               /* Out of proximity, clear wheel value. */
 +               input_report_abs(input, ABS_WHEEL, 0);
 +
 +       if (data[1] | (data[2]  0x01) | data[3]) {
 +               input_report_key(input, wdata-tool, 1);
 +               input_report_key(input, BTN_TOOL_FINGER, 1);
 +       } else {
 +               input_report_key(input, wdata-tool, 0);
 +               input_report_abs(input, BTN_TOOL_FINGER, 0);
 +       }

I'm assuming your sending BTN_TOOL_FINGER because thats what Intuos4
does in wacom_wac.c kernel driver?

For drivers that want to use Protocol 4 or  5 style events (see
http://sourceforge.net/apps/mediawiki/linuxwacom/index.php?title=Kernel_Input_Event_Overview
), this does inform xf86-input-wacom to treat these as PAD events
so, for example, ABS_WHEEL is treated as a wheel on PAD device and not
a wheel on mouse puck or airbrush.

But Protocol 4and 5 drivers are also required to send a value in
ABS_MISC as described in above link.  If not, the serial # is stuck
with fixed value of zero and then the same data structure in
xf86-input-wacom will be used to store all events for all hotplugged
devices.  I'm not exactly sure what that would visually result in but
I assume if you leave pen in proximity while you click a tablet button
that the pen would be forced out of proximity when you release the
button.  Or maybe jump to location (0,0).

One option is to update xf86-input-wacom so that driver does not have
to send serial #'s always.  Over last year, xf86-input-wacom::wcmUSB.c
has added a function called usbInitToolType() that peeks at all
buffered events to detect tool type.  Right now, it only does it to
see which hotplug device type to send events to.  We could also change
to decide which data structure/array location (called channel
internally) as well;  We could at least do this for the PAD device
which is always force to last channel by convention.

I do not know if these Bluetooth Intuos4 support mouse pucks.  If so,
then we have to become concerned with only 1 tool with overlapping
ABS_WHEEL events are allowed in proximity at the same time.

Chris

 +       input_sync(input);
 +}
 +
  static void wacom_i4_parse_report(struct hid_device *hdev,
                        struct wacom_data *wdata,
                        struct input_dev *input, unsigned char *data)
 @@ -377,6 +406,7 @@     case 0x03: /* Features Report */
                wdata-features = data[2];
                break;
        case 0x0C: /* Button report */
 +               wacom_i4_parse_pad_report(wdata, input, data);
                break;
        default:
                hid_err(hdev, Unknown report: %d,%d\n, data[0], data[1]);
 @@ -474,6 +504,14 @@            input_set_abs_params(input, ABS_DISTAN
                input_set_abs_params(input, ABS_X, 0, 40640, 4, 0);
                input_set_abs_params(input, ABS_Y, 0, 25400, 4, 0);
                input_set_abs_params(input, ABS_PRESSURE, 0, 2047, 0, 0);
 +               input_set_abs_params(input, ABS_WHEEL, 0, 71, 0, 0);
 +               __set_bit(BTN_2, input-keybit);
 +               __set_bit(BTN_3, input-keybit);
 +               __set_bit(BTN_4, input-keybit);
 +               __set_bit(BTN_5, input-keybit);
 +               __set_bit(BTN_6, input-keybit);
 +               __set_bit(BTN_7, input-keybit);
 +               __set_bit(BTN_8, input-keybit);
                break;
        }


 --
 Keep Your Developer Skills Current with LearnDevNow

Re: [Linuxwacom-devel] [PATCH] hid-wacom: add support to Intuos4 pad buttons and dial

[Chris Bagwell]

When I mention ABS_MISC, it should really be MSC_SERIAL.  But the link
I sent tells it all better.

Chris

On Thu, Feb 2, 2012 at 9:32 AM, Chris Bagwell ch...@cnpbagwell.com wrote:
 Hi Aristeu,

 I'm sure people will be happy to see this patch.  I've a question for you 
 below.

 On Wed, Feb 1, 2012 at 11:23 AM, Aristeu Rozanski a...@redhat.com wrote:
 This patch adds support for the pad buttons and dial in the bluetooth version
 of Intuos4.

 Signed-off-by: Aristeu Rozanski a...@redhat.com

 ---
  drivers/hid/hid-wacom.c |   38 ++
  1 file changed, 38 insertions(+)

 --- linus-2.6.orig/drivers/hid/hid-wacom.c      2012-02-01 
 11:54:09.0 -0500
 +++ linus-2.6/drivers/hid/hid-wacom.c   2012-02-01 12:17:46.166583951 -0500
 @@ -363,6 +363,35 @@            input_report_key(input, BTN_STYLUS2, d
        return;
  }

 +static void wacom_i4_parse_pad_report(struct wacom_data *wdata,
 +                       struct input_dev *input, unsigned char *data)
 +{
 +       input_report_key(input, BTN_0, (data[2]  0x01));
 +       input_report_key(input, BTN_1, (data[3]  0x01));
 +       input_report_key(input, BTN_2, (data[3]  0x02));
 +       input_report_key(input, BTN_3, (data[3]  0x04));
 +       input_report_key(input, BTN_4, (data[3]  0x08));
 +       input_report_key(input, BTN_5, (data[3]  0x10));
 +       input_report_key(input, BTN_6, (data[3]  0x20));
 +       input_report_key(input, BTN_7, (data[3]  0x40));
 +       input_report_key(input, BTN_8, (data[3]  0x80));
 +
 +       if (data[1]  0x80)
 +               input_report_abs(input, ABS_WHEEL, (data[1]  0x7f));
 +       else
 +               /* Out of proximity, clear wheel value. */
 +               input_report_abs(input, ABS_WHEEL, 0);
 +
 +       if (data[1] | (data[2]  0x01) | data[3]) {
 +               input_report_key(input, wdata-tool, 1);
 +               input_report_key(input, BTN_TOOL_FINGER, 1);
 +       } else {
 +               input_report_key(input, wdata-tool, 0);
 +               input_report_abs(input, BTN_TOOL_FINGER, 0);
 +       }

 I'm assuming your sending BTN_TOOL_FINGER because thats what Intuos4
 does in wacom_wac.c kernel driver?

 For drivers that want to use Protocol 4 or  5 style events (see
 http://sourceforge.net/apps/mediawiki/linuxwacom/index.php?title=Kernel_Input_Event_Overview
 ), this does inform xf86-input-wacom to treat these as PAD events
 so, for example, ABS_WHEEL is treated as a wheel on PAD device and not
 a wheel on mouse puck or airbrush.

 But Protocol 4and 5 drivers are also required to send a value in
 ABS_MISC as described in above link.  If not, the serial # is stuck
 with fixed value of zero and then the same data structure in
 xf86-input-wacom will be used to store all events for all hotplugged
 devices.  I'm not exactly sure what that would visually result in but
 I assume if you leave pen in proximity while you click a tablet button
 that the pen would be forced out of proximity when you release the
 button.  Or maybe jump to location (0,0).

 One option is to update xf86-input-wacom so that driver does not have
 to send serial #'s always.  Over last year, xf86-input-wacom::wcmUSB.c
 has added a function called usbInitToolType() that peeks at all
 buffered events to detect tool type.  Right now, it only does it to
 see which hotplug device type to send events to.  We could also change
 to decide which data structure/array location (called channel
 internally) as well;  We could at least do this for the PAD device
 which is always force to last channel by convention.

 I do not know if these Bluetooth Intuos4 support mouse pucks.  If so,
 then we have to become concerned with only 1 tool with overlapping
 ABS_WHEEL events are allowed in proximity at the same time.

 Chris

 +       input_sync(input);
 +}
 +
  static void wacom_i4_parse_report(struct hid_device *hdev,
                        struct wacom_data *wdata,
                        struct input_dev *input, unsigned char *data)
 @@ -377,6 +406,7 @@     case 0x03: /* Features Report */
                wdata-features = data[2];
                break;
        case 0x0C: /* Button report */
 +               wacom_i4_parse_pad_report(wdata, input, data);
                break;
        default:
                hid_err(hdev, Unknown report: %d,%d\n, data[0], data[1]);
 @@ -474,6 +504,14 @@            input_set_abs_params(input, ABS_DISTAN
                input_set_abs_params(input, ABS_X, 0, 40640, 4, 0);
                input_set_abs_params(input, ABS_Y, 0, 25400, 4, 0);
                input_set_abs_params(input, ABS_PRESSURE, 0, 2047, 0, 0);
 +               input_set_abs_params(input, ABS_WHEEL, 0, 71, 0, 0);
 +               __set_bit(BTN_2, input-keybit);
 +               __set_bit(BTN_3, input-keybit);
 +               __set_bit(BTN_4, input-keybit);
 +               __set_bit(BTN_5, input-keybit);
 +               __set_bit(BTN_6, input-keybit);
 +               __set_bit(BTN_7, input-keybit

Re: [Linuxwacom-devel] [PATCH] hid-wacom: add support to Intuos4 pad buttons and dial

[Chris Bagwell]

On Thu, Feb 2, 2012 at 10:08 AM, Aristeu Rozanski a...@redhat.com wrote:
 On Thu, Feb 02, 2012 at 09:32:03AM -0600, Chris Bagwell wrote:
 Hi Aristeu,

 I'm sure people will be happy to see this patch.  I've a question for you 
 below.

 On Wed, Feb 1, 2012 at 11:23 AM, Aristeu Rozanski a...@redhat.com wrote:
  This patch adds support for the pad buttons and dial in the bluetooth 
  version
  of Intuos4.
 
  Signed-off-by: Aristeu Rozanski a...@redhat.com
 
  ---
   drivers/hid/hid-wacom.c |   38 ++
   1 file changed, 38 insertions(+)
 
  --- linus-2.6.orig/drivers/hid/hid-wacom.c      2012-02-01 
  11:54:09.0 -0500
  +++ linus-2.6/drivers/hid/hid-wacom.c   2012-02-01 12:17:46.166583951 -0500
  @@ -363,6 +363,35 @@            input_report_key(input, BTN_STYLUS2, d
         return;
   }
 
  +static void wacom_i4_parse_pad_report(struct wacom_data *wdata,
  +                       struct input_dev *input, unsigned char *data)
  +{
  +       input_report_key(input, BTN_0, (data[2]  0x01));
  +       input_report_key(input, BTN_1, (data[3]  0x01));
  +       input_report_key(input, BTN_2, (data[3]  0x02));
  +       input_report_key(input, BTN_3, (data[3]  0x04));
  +       input_report_key(input, BTN_4, (data[3]  0x08));
  +       input_report_key(input, BTN_5, (data[3]  0x10));
  +       input_report_key(input, BTN_6, (data[3]  0x20));
  +       input_report_key(input, BTN_7, (data[3]  0x40));
  +       input_report_key(input, BTN_8, (data[3]  0x80));
  +
  +       if (data[1]  0x80)
  +               input_report_abs(input, ABS_WHEEL, (data[1]  0x7f));
  +       else
  +               /* Out of proximity, clear wheel value. */
  +               input_report_abs(input, ABS_WHEEL, 0);
  +
  +       if (data[1] | (data[2]  0x01) | data[3]) {
  +               input_report_key(input, wdata-tool, 1);
  +               input_report_key(input, BTN_TOOL_FINGER, 1);
  +       } else {
  +               input_report_key(input, wdata-tool, 0);
  +               input_report_abs(input, BTN_TOOL_FINGER, 0);
  +       }

 I'm assuming your sending BTN_TOOL_FINGER because thats what Intuos4
 does in wacom_wac.c kernel driver?
 yep.

 For drivers that want to use Protocol 4 or  5 style events (see
 http://sourceforge.net/apps/mediawiki/linuxwacom/index.php?title=Kernel_Input_Event_Overview
 ), this does inform xf86-input-wacom to treat these as PAD events
 so, for example, ABS_WHEEL is treated as a wheel on PAD device and not
 a wheel on mouse puck or airbrush.
 but that's intended. it's a wheel on the side of the tablet:
  === +-+
  === |                             |
  === |                             |
  === |                             |
  w  |                             |
  w=w |                             |
  w  |                             |
  === |                             |
  === |                             |
  === |                             |
  === +-+

 But Protocol 4and 5 drivers are also required to send a value in
 ABS_MISC as described in above link.  If not, the serial # is stuck
 with fixed value of zero and then the same data structure in
 xf86-input-wacom will be used to store all events for all hotplugged
 devices.  I'm not exactly sure what that would visually result in but
 I assume if you leave pen in proximity while you click a tablet button
 that the pen would be forced out of proximity when you release the
 button.  Or maybe jump to location (0,0).

 One option is to update xf86-input-wacom so that driver does not have
 to send serial #'s always.  Over last year, xf86-input-wacom::wcmUSB.c
 has added a function called usbInitToolType() that peeks at all
 buffered events to detect tool type.  Right now, it only does it to
 see which hotplug device type to send events to.  We could also change
 to decide which data structure/array location (called channel
 internally) as well;  We could at least do this for the PAD device
 which is always force to last channel by convention.

 I do not know if these Bluetooth Intuos4 support mouse pucks.  If so,
 then we have to become concerned with only 1 tool with overlapping
 ABS_WHEEL events are allowed in proximity at the same time.
 thanks for the explanation, I never fully got the reason for the serial.
 I'll rework the patch to get it right.


OK.  Good luck and feel free to ask question.

I'm not convinced myself yet if its a kernel side or X input side
design issue yet so updates to either side are an option.  But sending
the serial # is also probably easiest change.

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

Re: [Linuxwacom-devel] [PATCH] hid-wacom: add support to Intuos4 pad buttons and dial

[Chris Bagwell]

On Thu, Feb 2, 2012 at 10:34 AM, Bastien Nocera had...@hadess.net wrote:
 On Thu, 2012-02-02 at 11:08 -0500, Aristeu Rozanski wrote:
  I do not know if these Bluetooth Intuos4 support mouse pucks.

 From what I've read (before stupidly buying the USB-only version), plug
 in the Intuos4 WL via USB and it's the same as the Intuos4 L. So I'm
 guessing it supports the exact same tools.


OK.  Thanks.

Come to think of it, there a few bigger issues to solve first.  For
now, I suggest ignoring my comment about
BTN_TOOL_MOUSE+BTN_TOOL_FINGER being in proximity at the same time and
just get stylus+pad buttons working without addressing.  Or at least
put it to back of your head. :-)

The issue is that right now, Protocol 5 devices have to be manually
added to a list in xf86-input-wacom so probably this bluetooth device
is treated as a Protocol 4 device.

One difference is serial # for PAD device is 0xff vs. -1 between the
two protocols so xf86-input-wacom will chose wrong channel if it
thinks its a Protocol 4.  The xf86-input-wacom logic could stand to be
rewritten to compute all channel #'s like it does for Protocol 5's
(look up an unused slot and ignore exact serial # value).

The ABS_DISTANCE also becomes very important for mice pucks and
Protocol 4 vs. 5 currently send it with inverse meaning.  And nothing
from kernel side advertises Protocol 4 vs. Protocol 5.  Thus the hard
coded list. Opps.

Protocol 4 doesn't give you anything beyond what we've come to call
Protocol Generic (simple tablets) so I've pushed to end-of-life
Protocol 4.  Since we do not have generic replacements for Protocol 5
concepts yet, it will need to stay around for a while.  Maybe we
should change default in xf86-input-wacom for unknown tablets with
serial #'s from Protocol 4 to Protocol 5?

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] libwacom

[Chris Bagwell]

On Thu, Feb 2, 2012 at 12:31 PM, Bastien Nocera had...@hadess.net wrote:
 On Thu, 2012-02-02 at 11:55 -0600, Favux ... wrote:
 Hi Bastien,

 Thanks for reviewing the wiki page.

 On Thu, Feb 2, 2012 at 10:31 AM, Bastien Nocera had...@hadess.net wrote:

  I think the information about filling in the definition files should be in
  wacom.example directly, and nothing (that would most likely end up being
  outdated) in the Wiki.

 I rather meant the advices about the naming of the device for example.
 You also probably want to use a definition that doesn't have FIXME in it
 as the example ;)

  The contributors list, which you seem to have snarfed from my blog entry, 
  are
  the
  contributors to the GNOME wacom support, not to libwacom. For example, 
  Jason
  didn't contribute until I committed his extensive definition files.

 Will correct that then.  Yes everything is cribbed off your blog and
 other posts and interviews.  And some of Peter's stuff.  If there is
 any original content it is probably accidental.  :)

 Haha.

  Other than that, the content is interesting, thanks.

 I don't know if you are interested but if you want to have at it and
 edit it Peter can add you to the wiki editor list.

  I do have another question.  When I look at the GNOME 3.4 Control
  Panel Wacom tablet applet rotation seems to apply the stylus parent
  device.  I can't tell if touch is also rotated for USB tablet PCs and
  BambooPTs with their separate parent device for touch.  Is it?
 
  Does it show up as a separate tool? If so, we don't support it yet in
  GsdWacomDevice, but adding it should be enough to get all the tools 
  rotated at
  once. Can you file a bug against gnome-settings-daemon in the GNOME 
  Bugzilla
  for
  that?

 When tested touch rotates fine for my BambooPT but not for my usb
 tablet PC.  That's with GNOME 3.2 as I haven't tested it yet with the
 GNOME 3.4 Control Panel.  The BambooPT's pad buttons don't rotate of
 course, but you haven't started working on those.


 A further issue concerns the generic styli.  The LLC (low low cost)
 consumer tablets like the Bamboo Pen and the Bamboo Ones have a stylus
 + 2 buttons but no eraser.

 Ha, I didn't know that. We need to create some new styli for those
 devices then.

 Peter, Jason, any advice on what tool IDs we could use for those?

I've not yet played with libwacom or new Gnome wacom work (trying to
wait until 2/7 when Fedora is supposed to branch from rawhide before I
upgrade a VM+software but its getting harder to wait.).  So I don't
know some of these terms but here is some extra info that may be
important.

Some models of Bamboo in same family+generation are sold with stylus
that have erasers.  I think, but I'm not sure, that its only a
packaging issue to save a few bucks and if you buy a replacement
stylus from same family+generation with an eraser that it would work.
Unfortunately, all my styli have erasers so I can not test this
theory.

That is only reason I've not pursued hiding the BTN_TOOL_ERASER on
these Bamboo devices in kernel driver.  I'd hate to take away a
feature from users.  I'm not sure how this would translate into
libwacom or Gnome support but the concept of Delayed Hotplugging
that's been discussed in the past may be useful here.


   That's true of some of the tablet PCs
 also.  Additionally if I recall correctly some tablet PCs have a
 stylus + 1 button.

 It's really the same problem. My Bluetooth graphire-based tablet has 2
 buttons, and an eraser. We need separate styli definition for them.

   Not sure if those styli have erasers or not.  On
 those models the driver tends to report a spurious eraser and pad
 (with the tablets) in say 'xinput list'.  Since libwacom removes the
 reporting of a spurious pad (Buttons=0) doing the same for the eraser
 or spurious side button would be nice.  Maybe Peter can tell us which
 styli those are?

 We don't count the tips. So a stylus always has one button, and an
 eraser always has one button. We would use HasEraser=false for the
 stylus though.

Here is some more info related to my Bamboo comment.  For Tablet PC's
(the ones that usually say something about ISDv4 in dmesg), I don't
have any personal experience but from reports I see it seems like for
a given generation there is only 1 type of stylus (maybe it has 0, 1,
or 2 buttons beyond the tip button and maybe it has an eraser or
not).  If you share a stylus between Tablet PC families+generations
with different buttons/eraser config there is a good change it will
work for stylus+tip but everything else is iffy.

For this cases, I think its probably best to take effort to hide
erasers and unsupported buttons per USB PID inside the kernel driver.
Its minor driver changes if my assumption could be proven 100%
accurate (which I can't do since I've never touch a Wacom Tablet PC).

But it also sounds like we are going to be able to hide it with
configuration file as well; which is great.

Chris

Re: [Linuxwacom-devel] Touchpad?

[Chris Bagwell]

On Sun, Jan 22, 2012 at 3:38 AM, Cedric Sodhi man...@gmx.net wrote:
 On Sat, Jan 21, 2012 at 06:15:35PM -0600, Chris Bagwell wrote:
 On Sat, Jan 21, 2012 at 2:31 PM, Cedric Sodhi man...@gmx.net wrote:
  On Sat, Jan 21, 2012 at 11:14:37PM +0700, Alexey Osipov wrote:
  Okay, I think I see the problem.
 
  You have a touchscreen device, not a touchpad, right?
 
  Touchscreen and touchpad behaviours are different in xf86-input-wacom.
 
  This difference determined by 'WCM_LCD' flag set on device in
  wcmDeviceTypeKeys() from wcmValidateDevice.c.
 
  Then, in wcmSingleFingerPress() from wcmTouchFilter.c this flag is being
  checked:
  - if it's ON, we make left button press when finger touches the screen
  and button release when finger outs. This seems to be your case.
  - if it's OFF, we just move the cursor. This seems to be my case. It
  seems that tap clicking and tap-and-drag works in this case only.
 
  So, if you are hacking sources anyway, you may try to remove WCM_LCD
  flag from your device and see if it helps.
 
 
  It should not even be set. the tablet_id is 0xA001 for the egalax,
  nothing in that sourcefile sets WCM_LCD then. Any idea why it's LCD
  anyway?
 
  I'll try to hack in an xinput setting to allow setting WCM_LCD on the
  fly.
 
  I already tried looking at xsetwacom.c but I could not make no heads nor
  tail of that. There was no enum, whatsoever, identifying the settings.
  Only strings. Bizarre.
 
  Alexey.

 Look for usbGenericTouchscreenQuirks() in wcmUSB.c to see how its
 detected as touchscreen.  WCM_TPC also sets WCM_LCD I think (or the
 other way around).

 Your asking for a touchscreen to not act as a touchscreen.  This will
 never be an accepted patch for either xf86-input-wacom or other
 touchscreen drivers such as xf86-input-evdev.

 They may accept support to say My touchpad was misdetected as a
 touchscreen, please treat as a touchpad but it doesn't exist in
 either xf86-input-wacom nor xf86-input-evdev right now.  You could use
 that as a way of getting what you want.

 Sounds like your on the right track to hack up the driver for what
 ever custom application you have.

 Why do you say that? I think this is an unreasonable thing to say.
 To start, this has nothing do to with a particular application. I simply
 want to be able to move the mouse without actually dragging it.

 How is that acting not as a touchscreen? A touchscreen acts by being
 touched. That's the definition of a touchscreen. And I could even admit
 that a common assumption is an absolute mapping. But that's about it.

 All that this would do is further generalize and unify touchpads and
 touchscreens - step that is long due, if you ask me.

 But well, I don't want to advance some philosophical argument: This is
 practically relevant and a reasonable thing to like.


Yep, all philosophical discussions.  Touchscreens have always sent
button press during touch since support originally added to Windows,
OS X, Linux, and just about any OS that starts first as a mouse
oriented OS.  Thats the defacto definition.  Nothing can really be
argued against that being the definition.

As I said, you may still be able to get what you want in this legacy
world.  You just need to state the problem and conform the solution to
the legacy world and talk about non-unified touchscreen vs. touchpad
behaviours.

I think you'll start getting happier once the new multi-touch stuff is
released.  We get to throw away alot of this legacy baggage; at least
for MT-aware apps.

Chris

--
Try before you buy = See our experts in action!
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-dev2
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] Touchpad?

[Chris Bagwell]

On Sat, Jan 21, 2012 at 2:31 PM, Cedric Sodhi man...@gmx.net wrote:
 On Sat, Jan 21, 2012 at 11:14:37PM +0700, Alexey Osipov wrote:
 Okay, I think I see the problem.

 You have a touchscreen device, not a touchpad, right?

 Touchscreen and touchpad behaviours are different in xf86-input-wacom.

 This difference determined by 'WCM_LCD' flag set on device in
 wcmDeviceTypeKeys() from wcmValidateDevice.c.

 Then, in wcmSingleFingerPress() from wcmTouchFilter.c this flag is being
 checked:
 - if it's ON, we make left button press when finger touches the screen
 and button release when finger outs. This seems to be your case.
 - if it's OFF, we just move the cursor. This seems to be my case. It
 seems that tap clicking and tap-and-drag works in this case only.

 So, if you are hacking sources anyway, you may try to remove WCM_LCD
 flag from your device and see if it helps.


 It should not even be set. the tablet_id is 0xA001 for the egalax,
 nothing in that sourcefile sets WCM_LCD then. Any idea why it's LCD
 anyway?

 I'll try to hack in an xinput setting to allow setting WCM_LCD on the
 fly.

 I already tried looking at xsetwacom.c but I could not make no heads nor
 tail of that. There was no enum, whatsoever, identifying the settings.
 Only strings. Bizarre.

 Alexey.

Look for usbGenericTouchscreenQuirks() in wcmUSB.c to see how its
detected as touchscreen.  WCM_TPC also sets WCM_LCD I think (or the
other way around).

Your asking for a touchscreen to not act as a touchscreen.  This will
never be an accepted patch for either xf86-input-wacom or other
touchscreen drivers such as xf86-input-evdev.

They may accept support to say My touchpad was misdetected as a
touchscreen, please treat as a touchpad but it doesn't exist in
either xf86-input-wacom nor xf86-input-evdev right now.  You could use
that as a way of getting what you want.

Sounds like your on the right track to hack up the driver for what
ever custom application you have.

Chris

--
Try before you buy = See our experts in action!
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-dev2
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] GIMP doesn't recognise pen and eraser.

[Chris Bagwell]

What version of hid-wacom.c is being used?  The version in Linus's try
doesn't report ABS_MISC for anything.

The values for ABS_MISC look invalid to me.

If the driver advertises itself as a Protocol 4 or 5 device and sends
invalid ABS_MISC's, xf86-input-wacom used to discard those packets.
Not sure if it still does.

Chris

On Thu, Jan 19, 2012 at 1:34 PM, Przemo Firszt prz...@firszt.eu wrote:
 Hi,
 The kernel driver for Inruos4 Wireles reports to the subsystem as follows for
 pen:

 wdata-tool = BTN_TOOL_PEN
 wdata-serial = 148056F6 (not sure if that's OK)
 wdata-id = 100802

 and for eraser:

 wdata-tool = BTN_TOOL_RUBBER
 wdata-serial = 148056F6
 wdata-id = 10080A

 snippet of the code responsible for reporting:
 [..]
 input_report_key(input, BTN_TOUCH, pressure  1);
 input_report_key(input, BTN_STYLUS, data[1]  0x02);
 input_report_key(input, BTN_STYLUS2, data[1]  0x04);
 input_report_abs(input, ABS_X, x);
 input_report_abs(input, ABS_Y, y);
 input_report_abs(input, ABS_PRESSURE, pressure);
 input_report_abs(input, ABS_MISC, wdata-id);
 input_event(input, EV_MSC, MSC_SERIAL, wdata-serial);
 input_report_key(input, wdata-tool, 1);
 input_sync(input);
 [..]
 yet gimp fails to recoginse pen vs. eraser.
 I'm missing something here or I should check how xorg driver for wacom 
 handles these values?

 --
 Regards,
 Przemo



--
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] GIMP doesn't recognise pen and eraser.

[Chris Bagwell]

On Thu, Jan 19, 2012 at 2:22 PM, Przemo Firszt prz...@firszt.eu wrote:
 Dnia 2012-01-19, czw o godzinie 14:12 -0600, Chris Bagwell pisze:
 What version of hid-wacom.c is being used?  The version in Linus's try
 doesn't report ABS_MISC for anything.

 The values for ABS_MISC look invalid to me.

 If the driver advertises itself as a Protocol 4 or 5 device and sends
 invalid ABS_MISC's, xf86-input-wacom used to discard those packets.
 Not sure if it still does.
 My custom version based on the latest git kernel. The important part is
 here: http://pastebin.com/dZMerS6p

 ABS_MISC value (wdata-serial) is copied from usb driver - could be
 wrong. What would you expect there?

 I don't want to upload that version to our git repo, cause it's very,
 very dirty..

Fair enough.

It should be same as wacom_wac.c.  One of this:

#define STYLUS_DEVICE_ID0x02
#define TOUCH_DEVICE_ID 0x03
#define CURSOR_DEVICE_ID0x06
#define ERASER_DEVICE_ID0x0A
#define PAD_DEVICE_ID   0x0F

Chris

 --
 Regards,
 Przemo


--
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] [PATCH v2] Enable LED status change through xsetwacom

[Chris Bagwell]

 wcmIsHotpluggedDevice(InputInfoPtr pInfo)
        return !strcmp(source, _driver/wacom);
  }

 +static void wcmStoreLEDsysfsInfo(InputInfoPtr pInfo)
 +{
 +       WacomDevicePtr  priv = (WacomDevicePtr)pInfo-private;
 +       WacomCommonPtr  common = priv-common;
 +       struct stat st;
 +       struct udev *udev = udev_new();
 +       struct udev_device *parent;
 +       struct udev_device *device;
 +       char fs_path[128], buf[10];
 +       int err = -1;
 +
 +       stat(common-device_path, st);
 +       device = udev_device_new_from_devnum(udev, 'c', st.st_rdev);
 +       if (!device)
 +               return;
 +
 +       parent = udev_device_get_parent_with_subsystem_devtype(device,
 +                usb, NULL);
 +
 +       if (!parent)
 +               return;
 +
 +       sprintf(fs_path, %s/wacom_led/status_led0_select,
 +               udev_device_get_syspath(parent));
 +       common-fd_sysfs0 = open(fs_path, O_RDWR);
 +       if (common-fd_sysfs0 = 0)
 +       {
 +               SYSCALL(err = read(common-fd_sysfs0, buf, 1));
 +               if (err  -1)
 +               {
 +                       xf86Msg(X_WARNING, %s: failed to get led0 status in 
 +                               wcmStoreLEDsysfsInfo.\n, pInfo-name);
 +               }
 +               else
 +                       common-led0_status = buf[0] - '0';
 +       }
 +       else
 +               DBG(2, common, No LED0 sysfs on %s for %s\n,
 +                                       fs_path, pInfo-name);
 +
 +       sprintf(fs_path, %s/wacom_led/status_led1_select,
 +               udev_device_get_syspath(parent));
 +       common-fd_sysfs1 = open(fs_path, O_RDWR);
 +       if (common-fd_sysfs1 = 0)
 +       {
 +               SYSCALL(err = read(common-fd_sysfs1, buf, 1));
 +               if (err  -1)
 +               {
 +                       xf86Msg(X_WARNING, %s: failed to get led1 status in 
 +                               wcmStoreLEDsysfsInfo.\n, pInfo-name);
 +               }
 +               else
 +                       common-led1_status = buf[0] - '0';
 +       }
 +       else
 +               DBG(2, common, No LED1 sysfs on %s for %s\n,
 +                                       fs_path, pInfo-name);

This is complicated enough that I'd factor it out into a function for
common behavior or at list make it a for() loop somehow.

Chris

 +}
 +
  /* wcmPreInit - called for each input devices with the driver set to
  * wacom */
  #if GET_ABI_MAJOR(ABI_XINPUT_VERSION)  12
 @@ -524,9 +584,14 @@ static int wcmPreInit(InputDriverPtr drv, InputInfoPtr 
 pInfo, int flags)

        /* check if this is the first tool on the port */
        if (!wcmMatchDevice(pInfo, common))
 +       {
                /* initialize supported keys with the first tool on the port */
                wcmDeviceTypeKeys(pInfo);

 +               /* store lED sysfs file descriptor and initial status */
 +               wcmStoreLEDsysfsInfo(pInfo);
 +       }
 +
        common-debugLevel = xf86SetIntOption(pInfo-options,
                                              CommonDBG, common-debugLevel);
        oldname = pInfo-name;
 diff --git a/src/wcmXCommand.c b/src/wcmXCommand.c
 index 40393dc..aec3fee 100644
 --- a/src/wcmXCommand.c
 +++ b/src/wcmXCommand.c
 @@ -1,5 +1,5 @@
  /*
 - * Copyright 2007-2010 by Ping Cheng, Wacom. pi...@wacom.com
 + * Copyright 2007-2012 by Ping Cheng, Wacom. pi...@wacom.com
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
 @@ -91,6 +91,7 @@ Atom prop_tv_resolutions;
  Atom prop_cursorprox;
  Atom prop_threshold;
  Atom prop_suppress;
 +Atom prop_led;
  Atom prop_touch;
  Atom prop_gesture;
  Atom prop_gesture_param;
 @@ -206,6 +207,10 @@ void InitWcmDeviceProperties(InputInfoPtr pInfo)
        values[1] = common-wcmRawSample;
        prop_suppress = InitWcmAtom(pInfo-dev, WACOM_PROP_SAMPLE, XA_INTEGER, 
 32, 2, values);

 +       values[0] = common-led0_status;
 +       values[1] = common-led1_status;
 +       prop_led = InitWcmAtom(pInfo-dev, WACOM_PROP_LED, XA_INTEGER, 8, 2, 
 values);
 +
        values[0] = common-wcmTouch;
        prop_touch = InitWcmAtom(pInfo-dev, WACOM_PROP_TOUCH, XA_INTEGER, 8, 
 1, values);

 @@ -695,6 +700,38 @@ int wcmSetProperty(DeviceIntPtr dev, Atom property, 
 XIPropertyValuePtr prop,
                        common-wcmSuppress = values[0];
                        common-wcmRawSample = values[1];
                }
 +       } else if (property == prop_led)
 +       {
 +               CARD8 *values;
 +
 +               if (prop-size != 2 || prop-format != 8)
 +                       return BadValue;
 +
 +               values = (CARD8*)prop-data;
 +
 +               if ((values[0]  0) || (values[0]  3))
 +                       return BadValue;
 +               else if ((common-fd_sysfs0 = 0)  !checkonly)
 +               {
 +                       char buf[10];
 +                       int err = -1;
 +                       sprintf

Re: [Linuxwacom-devel] [PATCH] lib: Don't export private symbols

[Chris Bagwell]

This uses a gnu-ish.  Not sure if this matters or if any of the other
xf86-input-* do this type stuff.

Once upon a time, there was a port of xf86-input-wacom to Solaris
using non-GNU linker.

Chris

On Wed, Jan 11, 2012 at 9:38 AM, Robert Ancell
robert.anc...@canonical.com wrote:
 Attached patch stops private symbols from being exported in the library
 (currently bus_from_str, bus_to_str, type_from_str)

 Thanks,
 --Robert Ancell

 --
 Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
 infrastructure or vast IT resources to deliver seamless, secure access to
 virtual desktops. With this all-in-one solution, easily deploy virtual
 desktops for less than the cost of PCs and save 60% on VDI infrastructure
 costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
 ___
 Linuxwacom-devel mailing list
 Linuxwacom-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel


--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] linuxwacom project - asustek eeenote tablet

[Chris Bagwell]

I'd like to summarize where we are with Eee Note's for mailing list archive.

Mike was able to log some USB packets when using tablet under Windows
and sent them to me directly.  This showed that the device works
almost exactly like a Bamboo tablet.  We were assuming it was more
TabletPC and thats why we were not having success.

Packets started flowing correctly after adding the USB PID to
hid-core's blacklist and then using this in Wacom driver:

+static const struct wacom_features wacom_features_0x179F =
+   { EeeNote ASUSTek Digitizer, WACOM_PKGLEN_BBFUN, 16480, 12410, 255,
+ 0, BAMBOO_PT, WACOM_INTUOS_RES, WACOM_INTUOS_RES };

There is one outstanding issue.  This device does not use the same
bits to indicate in-proximity that Bamboo's/TabletPC's are using but
everything else is the same.  For the short term, you can edit the
file wacom_wac.c and modify the function wacom_bpt_pen().  Look for
line that says:

  prox = (data[1]  0x20) == 0x20;   --- Linux 3.3 or later

or

  prox = (data[1]  0x30) == 0x30;  --- Linux 3.2 or earlier

and change that to:

  prox = (data[1]  0x10) == 0x10;

I will see if there is a bit that is common between all products that
we can use for in-proximity or if there is some kind of if() statement
we can add to work with multiple product types.

Chris

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH 2/2] Add a new property: WACOM_PROP_ENABLE_MT

[Chris Bagwell]

On Mon, Jan 9, 2012 at 7:51 AM, Ping Cheng pingli...@gmail.com wrote:
 On Sun, Jan 8, 2012 at 9:56 PM, Peter Hutterer peter.hutte...@who-t.net
 wrote:

 On Sun, Jan 08, 2012 at 12:16:57AM -0800, Ping Cheng wrote:
  On Saturday, January 7, 2012, Chris Bagwell ch...@cnpbagwell.com
  wrote:
   What was the usecase for this again?
 
  The goal was to disable touch events when there are more than one touch
  on
  the tablet while wcmMT is off. That is, we only report touch events when
  there is only one touch on the tablet.
 what's the use-case for that though? You're essentially saying you want to
 disable multitouch but still report one touch? At what point is this
 useful?


 Yes, we want to report ST when there is only one finger on the tablet. We do
 not want to report ST when more than one fingers are on the tablet.

 The server (1.12) only does pointer emulation for one touchpoint anyway
 and
 any client that actually handles touch events is rather expected to deal
 with multiple ones. Same with the in-driver touch support.


 With your above comments, I know you are going to come back another
 question: why do you want to do that?. ;-）Well, it is becaue the kernel MT
 driver doesn't do the job for us. The way that the kernel input-mt.c
 emulates ST causes too  much jumps while changing from ST to MT and vice
 verse. Our customers, whose apps only support ST, can not accept those
 jumps. They'd rather only receive reliable ST when there is only one finger
 moving.


I'd like to understand this better if ya don't mind.

First up, is this usecase for absolute or relative mode?  I'll phrase
it like that instead of touchscreen/touchpad since some people put
touchpad in absolute mode.  Also, are gestures enabled or disabled?

For relative mode, Alexey just submitted a nice bug fix that may fix
what your really worried about.  Previously, during
gestures-with-no-movement we were not storing updated X/Y movement so
when you released gesture you'd get a big jump.  I believe this was
seen mostly during transition from 2 fingers to 1 finger (the case
your talking about).

Maybe you should try today's git and see if the issue is reproducible any more.

Now on the ST vs. MT part.  xf86-input-wacom doesn't know ST vs. MT.
Its always MT to it.  Sometimes its a MT with a count of 1 but still
MT.  So if we are seeing unwanted jumps during touch transitions, I'd
like to understand that better because I think there are real
xf86-input-wacom bugs to fix beyond giving an optional disable.

I'm actually a little surprised that ignoring MT events and looking at
only ST events helps instead of hurts.  At least in
xf86-input-synatpics, there is special logic to detect transition of
fingers and to account for an expected cursor jump in ST values.

Probably, for wacom it depends on finger release order.  If you
release 1st finger before 2nd finger then you should see a nice cursor
jump since finger tracking is forced to move to only remaining finger.

Chris

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH 1/2] Add 0xE5 (Tablet PC with 10FGT) support

[Chris Bagwell]

I've already forgotten what your driver patch looks like... but this
shouldn't technically be needed, right?  If the TPC's are still not
advertising BTN_TOOL_FINGER then there is code to auto add WCM_TPC in
wcmUSB.c

Anyways, its not like it hurts anything:

Reviewed-by: Chris Bagwell ch...@cnpbagwell.com

On Fri, Jan 6, 2012 at 7:57 PM, Ping Cheng pingli...@gmail.com wrote:
 Signed-off-by: Ping Cheng pi...@wacom.com
 ---
  src/wcmUSB.c            |    3 ++-
  src/wcmValidateDevice.c |    3 ++-
  2 files changed, 4 insertions(+), 2 deletions(-)

 diff --git a/src/wcmUSB.c b/src/wcmUSB.c
 index 8451c25..ba88696 100644
 --- a/src/wcmUSB.c
 +++ b/src/wcmUSB.c
 @@ -1,6 +1,6 @@
  /*
  * Copyright 1995-2002 by Frederic Lepied, France. lep...@xfree86.org
 - * Copyright 2002-2010 by Ping Cheng, Wacom. pi...@wacom.com
 + * Copyright 2002-2012 by Ping Cheng, Wacom. pi...@wacom.com
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
 @@ -273,6 +273,7 @@ static struct
        { WACOM_VENDOR_ID, 0x9F, 10, 10, usbTabletPC   }, /* CapPlus  
 0x9F */
        { WACOM_VENDOR_ID, 0xE2, 10, 10, usbTabletPC   }, /* TabletPC 
 0xE2 */
        { WACOM_VENDOR_ID, 0xE3, 10, 10, usbTabletPC   }, /* TabletPC 
 0xE3 */
 +       { WACOM_VENDOR_ID, 0xE5, 10, 10, usbTabletPC   }, /* 
 TabletPC 0xE5 */
        { WACOM_VENDOR_ID, 0xE6, 10, 10, usbTabletPC   }, /* TabletPC 
 0xE6 */

        /* IDs from Waltop's driver, available 
 http://www.waltop.com.tw/download.asp?lv=0id=2.
 diff --git a/src/wcmValidateDevice.c b/src/wcmValidateDevice.c
 index 862e005..0e0e57a 100644
 --- a/src/wcmValidateDevice.c
 +++ b/src/wcmValidateDevice.c
 @@ -1,5 +1,5 @@
  /*
 - * Copyright 2009 - 2010 by Ping Cheng, Wacom. pi...@wacom.com
 + * Copyright 2009 - 2012 by Ping Cheng, Wacom. pi...@wacom.com
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
 @@ -263,6 +263,7 @@ int wcmDeviceTypeKeys(InputInfoPtr pInfo)

                case 0xE2: /* TPC with 2FGT */
                case 0xE3: /* TPC with 2FGT */
 +               case 0xE5: /* TPC with 10FGT*/
                case 0xE6: /* TPC with 2FGT */
                        TabletSetFeature(priv-common, WCM_TPC);
                        break;
 --
 1.7.6.4


 --
 Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
 infrastructure or vast IT resources to deliver seamless, secure access to
 virtual desktops. With this all-in-one solution, easily deploy virtual
 desktops for less than the cost of PCs and save 60% on VDI infrastructure
 costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
 ___
 Linuxwacom-devel mailing list
 Linuxwacom-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH 2/2] Add a new property: WACOM_PROP_ENABLE_MT

[Chris Bagwell]

What was the usecase for this again?  I probably have minor comments
on code but it would help if I knew usecase so I don't suggest
something that would break it.

Is there some case were MT events are causing invalid behaviour?

Also, there is some commented out debug code that should be removed
before committing.

Chris

On Fri, Jan 6, 2012 at 7:57 PM, Ping Cheng pingli...@gmail.com wrote:
 This property enables/disables multi-touch events on a multi-touch
 device. When MT is disabled, the device behaves like a single
 touch device. The corresponding xorg.conf option is also added.

 Signed-off-by: Ping Cheng pi...@wacom.com
 ---
  include/wacom-properties.h |    3 +++
  man/wacom.man              |    3 +++
  src/wcmCommon.c            |   19 ---
  src/wcmUSB.c               |    9 ++---
  src/wcmValidateDevice.c    |    4 
  src/wcmXCommand.c          |   18 +-
  src/xf86WacomDefs.h        |    3 ++-
  tools/xsetwacom.c          |   10 ++
  8 files changed, 61 insertions(+), 8 deletions(-)

 diff --git a/include/wacom-properties.h b/include/wacom-properties.h
 index 0bb84b1..aa43d4d 100644
 --- a/include/wacom-properties.h
 +++ b/include/wacom-properties.h
 @@ -77,6 +77,9 @@
  #define WACOM_PROP_TOUCH Wacom Enable Touch

  /* 8 bit, 1 values */
 +#define WACOM_PROP_ENABLE_MT Wacom Enable Multi-Touch
 +
 +/* 8 bit, 1 values */
  #define WACOM_PROP_ENABLE_GESTURE Wacom Enable Touch Gesture

  /* 32 bit, 3 values, zoom, rotate, tap parameters */
 diff --git a/man/wacom.man b/man/wacom.man
 index 3d4a143..04d84a7 100644
 --- a/man/wacom.man
 +++ b/man/wacom.man
 @@ -225,6 +225,9 @@ sets the pressure threshold used to generate a button 1 
 events of stylus.
  The threshold applies to the normalised pressure range of [0..2048].
  The default is 27.
  .TP 4
 +.B Option \fIMulti-Touch\fP \fIbool\fP
 +Enable or disable multi-touch events on the device. Default: on.
 +.TP 4
  .B Option \fIGesture\fP \fIbool\fP
  Enable or disable gesture support on the device. Default: off unless the
  tablet supports multi-touch.
 diff --git a/src/wcmCommon.c b/src/wcmCommon.c
 index 0f041e3..cf1e5c2 100644
 --- a/src/wcmCommon.c
 +++ b/src/wcmCommon.c
 @@ -1,6 +1,6 @@
  /*
  * Copyright 1995-2002 by Frederic Lepied, France. lep...@xfree86.org
 - * Copyright 2002-2010 by Ping Cheng, Wacom. pi...@wacom.com
 + * Copyright 2002-2012 by Ping Cheng, Wacom. pi...@wacom.com
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
 @@ -1009,8 +1009,21 @@ void wcmEvent(WacomCommonPtr common, unsigned int 
 channel,
        pChannel-valid.state = ds; /*save last raw sample */
        if (pChannel-nSamples  common-wcmRawSample) ++pChannel-nSamples;

 -       if ((ds.device_type == TOUCH_ID)  common-wcmTouch)
 -               wcmGestureFilter(priv, channel);
 +       if ((ds.device_type == TOUCH_ID)  (common-wcmTouch))
 +       {
 +               /* enable left click for single touch touchscreen */
 +/*             if ((!common-wcmMT ||
 +                       TabletSetFeature(priv-common, WCM_1FGT)) 
 +                       TabletHasFeature(priv-common, WCM_LCD))
 +               {
 +                       if (ds.proximity)
 +                               pChannel-valid.state.buttons |= 1;
 +                       else
 +                               pChannel-valid.state.buttons = ~1;
 +               }
 +               else
 +*/                     wcmGestureFilter(priv, channel);
 +       }

        /* For touch, only first finger moves the cursor */
        if ((ds.device_type == TOUCH_ID  common-wcmTouch  !channel) ||
 diff --git a/src/wcmUSB.c b/src/wcmUSB.c
 index ba88696..9ace8a1 100644
 --- a/src/wcmUSB.c
 +++ b/src/wcmUSB.c
 @@ -582,6 +582,8 @@ int usbWcmGetRanges(InputInfoPtr pInfo)
        if (ISBITSET(abs, ABS_MT_SLOT))
        {
                private-wcmUseMT = 1;
 +               if (!common-wcmMT)
 +                       private-wcmUseMT = 0;

                /* pen and MT on the same logical port */
                if (ISBITSET(common-wcmKeys, BTN_TOOL_PEN))
 @@ -1210,9 +1212,10 @@ static int usbParseKeyEvent(WacomCommonPtr common,
                case BTN_TOUCH:
                        if (common-wcmProtocolLevel == WCM_PROTOCOL_GENERIC)
                        {
 -                               /* 1FG USB touchscreen */
 +                               /* 1FG USB touchscreen or MT disabled */
                                if (!TabletHasFeature(common, WCM_PEN) 
 -                                       TabletHasFeature(common, WCM_1FGT) 
 +                                       (TabletHasFeature(common, WCM_1FGT) ||
 +                                       !common-wcmMT) 
                                        TabletHasFeature(common, WCM_LCD))
                                {
                                        DBG(6, common,
 @@ -1525,7 +1528,7 @@ static void usbDispatchEvents

[Linuxwacom-devel] Bamboo Wireless Support

[Chris Bagwell]

Hi all,

If you have one of the newer Bamboo tablets and also have the optional
wireless module then I have some good news for you.  I have an initial
driver to add wireless support.

I'm looking for people with the optional wireless module to help test
with the various versions of the 3rd gen Bamboo tablet and different
USB hubs.  You need to be comfortable with git and building linux
kernels since I currently only have it as a branch off input-wacom.

Basic directions to get the new driver and test it:

git clone git://github.com/cbagwell/input-wacom.git -b wireless_draft
cd input-wacom
./autogen.sh
cd 2.6.38
sudo rmmod wacom
sudo insmod ./wacom.ko

I hope to add rfkill support next so that the receiver plays nice in
airplane mode.  After that, I'll see if there are other options the
Windows driver has that seem useful under Linux as well (it has a
power savings setting that looks interesting).

Chris

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH] release.sh: set announces' Reply-To to the linuxwacom-discuss

[Chris Bagwell]

Thanks Peter.

Reviewed-by: Chris Bagwell ch...@cnpbagwell.com


On Thu, Jan 5, 2012 at 9:27 PM, Peter Hutterer peter.hutte...@who-t.net wrote:
 Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
 ---
 Chris, this should do the trick provided the email client on the release
 manager's side honours Reply-To.

  release.sh |    2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

 diff --git a/release.sh b/release.sh
 index 5daa02a..3fe3a56 100755
 --- a/release.sh
 +++ b/release.sh
 @@ -6,6 +6,7 @@
  set -e

  announce_list=linuxwacom-annou...@lists.sourceforge.net
 +discuss_list=linuxwacom-disc...@lists.sourceforge.net
  module=xf86-input-wacom
  user=${USER}@
  host=shell.sourceforge.net
 @@ -53,6 +54,7 @@ SHA1SUM=`which sha1sum || which gsha1sum`
     cat RELEASE
  Subject: [ANNOUNCE] $module $version
  To: $announce_list
 +Reply-To: $discuss_list

  `git log --no-merges $range | git shortlog`

 --
 1.7.7.4


--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] linuxwacom project - asustek eeenote tablet

[Chris Bagwell]

It wasn't the debug interface I was looking for (its the HID debug
interface which filters packets) but it gives enough info to see whats
happening.

The device is stuck in mouse mode and only sending 5 byte mouse
packets.  Its not responding to the standard Tablet PC request to go
into Wacom mode.

There is some unique command that probably needs to be sent to device
to switch modes but there is no way to guess this value.

You could see if Asus released the source code to their probably
custom wacom driver and use it.

Or if your able to get debugfs and usbmon working on Asus's original
Linux distro, you can monitor the USB packet it sends when you do a
rmmod followed by a insmod of their driver.  Then we'd know what to
add to modern wacom drivers.

Without the info, I'm afraid we are at a dead end.

Chris

2012/1/4 Mike Rolland none...@gmail.com:
 well, i have no /sys/kernel/debug/usb/usbmon/2u but there is a
 /sys/kernel/debug/hid/0003\:0B05\:179F.0001/rdesc and
 /sys/kernel/debug/hid/0003\:0B05\:179F.0001/events

 events start from upleft corner to upright, bottom, bottom left and diagonal
 from upleft to bottom right.
 hope it helps

 M.

 Le mercredi 04 janvier 2012 à 12:56 +0400, Mike Rolland a écrit :

 Little trouble here...
 I've mounted debugfs, but usb dir just show devices list file.
 Have I to activate some other debug in kernel conf ? (this is a first time
 for me)

 Le mardi 03 janvier 2012 à 10:23 -0600, Chris Bagwell a écrit :

 On Tue, Jan 3, 2012 at 4:21 AM, Mike Rolland none...@gmail.com wrote:
 I was beginning to loose my self in all this advices.
 I had needs to clean my brain and go from start, so like suggest Chris, I
 revert all and change my kernel like this to separate multi device thing
 and
 clarify my-self :

 Index: drivers/hid/hid-ids.h
 ===
 --- drivers/hid/hid-ids.h
 +++ drivers/hid/hid-ids.h 2012-01-03 13:05:37.030924428 +0400
 @@ -135,6 +135,7 @@
 #define USB_DEVICE_ID_ASUSTEK_MULTITOUCH_YFO 0x0186

 #define USB_VENDOR_ID_ASUSTEK 0x0b05
 +#define USB_DEVICE_ID_ASUSTEK_DIGITIZER 0x179f
 #define USB_DEVICE_ID_ASUSTEK_LCM 0x1726
 #define USB_DEVICE_ID_ASUSTEK_LCM2 0x175b

 Index: drivers/hid/usbhid/hid-quirks.c
 ===
 --- drivers/hid/usbhid/hid-quirks.c
 +++ drivers/hid/usbhid/hid-quirks.c 2012-01-03 13:08:07.210924957 +0400
 @@ -91,6 +91,7 @@
 { USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_MULTI_TOUCH,
 HID_QUIRK_MULTI_INPUT },
 { USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_WIRELESS,
 HID_QUIRK_MULTI_INPUT },
 { USB_VENDOR_ID_SIGMA_MICRO, USB_DEVICE_ID_SIGMA_MICRO_KEYBOARD,
 HID_QUIRK_NO_INIT_REPORTS },
 + { USB_VENDOR_ID_ASUSTEK, USB_DEVICE_ID_ASUSTEK_DIGITIZER,
 HID_QUIRK_MULTI_INPUT }, /* experimental */
 { 0, 0 }
 };

 All reports are in the attached file because the 40ko mailing list limits.
 My conclusion are :
 Device is known as 2 devices.
 - touchscreen
 - mouse
 So, I wonder if we shouldn't point on 1 of this device to start Wacom
 driver
 change (or both, depends).

 The wacom driver has been coded such that it skips over that mouse
 device when querying the device and I *think* sends a command to
 device that says stop sending mouse data and start sending pen data
 (I'm not positive about this for TABLETPC's).

 On the EeeNote webpage tablet is implicitly declare as a Wacom one, and
 windows drivers for digitizer is from Wacom. There is no doubt about this.

 With experimental changes evtest stay squared in the left corner, and the
 first time I launched after driver change cursor was effectively squared
 there.

 It does do several things that seem like Wacom devices but I'm
 starting to suspect its a new version of hardware that sends a new
 packet format.


 Now, with revert to initial and quirk, mouse event are good and acts like
 mouse cursor in a 1024x768 pixel rectangle (nearby).
 Touchscreen mode report no events in evtest and really don't know how
 configure it with evdev and Xorg, so I can't tell you more.

 This makes some sense I think.  When an interface support multiple
 report types, it will send only the first one until something tells it
 to send the other type.  I've seen some eGalax touchscreens that put
 the touchscreen first and mouse second so by default it sends
 touchscreen coordinates.

 Wacom devices have always put mouse first in HID reports I've seen.

 So I guess that means you will require a custom driver to set up your
 digitizer correctly and probably its the wacom driver where it needs
 to do this.


 Because there is no error in kernel compilation, I suppose I didn't make
 mistakes with my change, I missed something and don't know what (probably
 because I'm not a hacker, lol)

 M.

 note: evtestX reports events with modified wacom drv in long X movement.
 evtestY, the same for Y movement.


 The reports showed the X doing something reasonable but a little
 questionable while the Y log seemed

Re: [Linuxwacom-devel] [PATCH input-wacom] Add missing input_mt_get_value() for 2.6.36/37

[Chris Bagwell]

Pushed.  Thanks.

On Wed, Jan 4, 2012 at 2:16 PM, Ping Cheng pingli...@gmail.com wrote:
 Compiled on 2.6.36 and .37. So,

 Acked-by: Ping Cheng pi...@wacom.com

 Ping

 On Thu, Dec 29, 2011 at 3:33 PM, ch...@cnpbagwell.com wrote:

 From: Chris Bagwell ch...@cnpbagwell.com

 Reported in bug tracker #3463769.

 Based on mini code review, I think this is only missing
 symbol and 2.6.36/37 contain ABS_MT_FIRST and input_mt_slot
 which this function depends on.

 I'm unable to test this fix but its a copypaste of
 function from mt.h in later kernels.
 ---
  2.6.36/wacom.h |    6 ++
  1 files changed, 6 insertions(+), 0 deletions(-)

 diff --git a/2.6.36/wacom.h b/2.6.36/wacom.h
 index 3117877..569ad9c 100644
 --- a/2.6.36/wacom.h
 +++ b/2.6.36/wacom.h
 @@ -94,6 +94,12 @@
  # endif
  #if LINUX_VERSION_CODE  KERNEL_VERSION(2,6,37)
  #include linux/input/mt.h
 +#else
 +static inline int input_mt_get_value(const struct input_mt_slot *slot,
 +                                     unsigned code)
 +{
 +        return slot-abs[code - ABS_MT_FIRST];
 +}
  #endif
  #include asm/unaligned.h

 --
 1.7.7.4



 --
 Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
 infrastructure or vast IT resources to deliver seamless, secure access to
 virtual desktops. With this all-in-one solution, easily deploy virtual
 desktops for less than the cost of PCs and save 60% on VDI infrastructure
 costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
 ___
 Linuxwacom-devel mailing list
 Linuxwacom-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel



--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] Multitouch?

[Chris Bagwell]

On Wed, Jan 4, 2012 at 4:34 PM, Cedric Sodhi man...@gmx.net wrote:
 Hello everyone,

 I hope you can shed a little light on this, multitouch is a complete
 mystery to me. I know that my eGalax is running fine with the
 hid-multitouch these days but I'm completely irritated as for what is
 required to actually get multitouch support in X.

 I didn't need it so far, but as of today, I do. I know my xorg (1.11.2)
 runs XI2, as I can get its values from xinput, but now? Currently, I'm
 still using the wacom driver for the eGalax, which doesn't seem very
 multitouchy to me.

 I know there is a bright and sunny future in the pipeline where
 everything is being reworked on the kernel an X side of things and
 everything will go up into the GREAT UNIFICATION OF X11 POINTERS, but
 that's about all I know.

 Could you provide a remote hint what I need to do so that the
 touchscreen's MT caps actually make it into X and don't die uselessly
 after the kernel handled it? In particular, I'd like a multitouch
 capable Qt application to pick it up.


Are you looking for simple gestures like a synaptics touchpad would
support?  If so then xf86-input-wacom is pretty good choice
(especially after upgrading to todays git, it has some good gesture
fixes).  Use xsetwacom or xinput to enable on touch device if they are
disabled by default.

Or are you looking for raw MT events so you can do your own gesture
logic?  If so then check out Peter's blog on near term X plumbing
updates: http://who-t.blogspot.com/

If you want things to be already nice and your toolkits provide some
nice abstraction then your out of luck.

Or perhaps you can install latest version of Ubuntu and check out
their uTouch stuff and any custom Qt patches they ship.  They are
probably furthest along with exposing MT to toolkits although their
API's are likely to change in each release since they are not using
the above official plumbing yet.

https://wiki.ubuntu.com/Multitouch

Chris

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] linuxwacom project - asustek eeenote tablet

[Chris Bagwell]

On Tue, Jan 3, 2012 at 4:21 AM, Mike Rolland none...@gmail.com wrote:
 I was beginning to loose my self in all this advices.
 I had needs to clean my brain and go from start, so like suggest Chris, I
 revert all and change my kernel like this to separate multi device thing and
 clarify my-self :

 Index: drivers/hid/hid-ids.h
 ===
 --- drivers/hid/hid-ids.h
 +++ drivers/hid/hid-ids.h 2012-01-03 13:05:37.030924428 +0400
 @@ -135,6 +135,7 @@
 #define USB_DEVICE_ID_ASUSTEK_MULTITOUCH_YFO 0x0186

 #define USB_VENDOR_ID_ASUSTEK 0x0b05
 +#define USB_DEVICE_ID_ASUSTEK_DIGITIZER 0x179f
 #define USB_DEVICE_ID_ASUSTEK_LCM 0x1726
 #define USB_DEVICE_ID_ASUSTEK_LCM2 0x175b

 Index: drivers/hid/usbhid/hid-quirks.c
 ===
 --- drivers/hid/usbhid/hid-quirks.c
 +++ drivers/hid/usbhid/hid-quirks.c 2012-01-03 13:08:07.210924957 +0400
 @@ -91,6 +91,7 @@
 { USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_MULTI_TOUCH,
 HID_QUIRK_MULTI_INPUT },
 { USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_WIRELESS,
 HID_QUIRK_MULTI_INPUT },
 { USB_VENDOR_ID_SIGMA_MICRO, USB_DEVICE_ID_SIGMA_MICRO_KEYBOARD,
 HID_QUIRK_NO_INIT_REPORTS },
 + { USB_VENDOR_ID_ASUSTEK, USB_DEVICE_ID_ASUSTEK_DIGITIZER,
 HID_QUIRK_MULTI_INPUT }, /* experimental */
 { 0, 0 }
 };

 All reports are in the attached file because the 40ko mailing list limits.
 My conclusion are :
 Device is known as 2 devices.
 - touchscreen
 - mouse
 So, I wonder if we shouldn't point on 1 of this device to start Wacom driver
 change (or both, depends).

The wacom driver has been coded such that it skips over that mouse
device when querying the device and I *think* sends a command to
device that says stop sending mouse data and start sending pen data
(I'm not positive about this for TABLETPC's).

 On the EeeNote webpage tablet is implicitly declare as a Wacom one, and
 windows drivers for digitizer is from Wacom. There is no doubt about this.

 With experimental changes evtest stay squared in the left corner, and the
 first time I launched after driver change cursor was effectively squared
 there.

It does do several things that seem like Wacom devices but I'm
starting to suspect its a new version of hardware that sends a new
packet format.


 Now, with revert to initial and quirk, mouse event are good and acts like
 mouse cursor in a 1024x768 pixel rectangle (nearby).
 Touchscreen mode report no events in evtest and really don't know how
 configure it with evdev and Xorg, so I can't tell you more.

This makes some sense I think.  When an interface support multiple
report types, it will send only the first one until something tells it
to send the other type.  I've seen some eGalax touchscreens that put
the touchscreen first and mouse second so by default it sends
touchscreen coordinates.

Wacom devices have always put mouse first in HID reports I've seen.

So I guess that means you will require a custom driver to set up your
digitizer correctly and probably its the wacom driver where it needs
to do this.


 Because there is no error in kernel compilation, I suppose I didn't make
 mistakes with my change, I missed something and don't know what (probably
 because I'm not a hacker, lol)

 M.

 note: evtestX reports events with modified wacom drv in long X movement.
 evtestY, the same for Y movement.


The reports showed the X doing something reasonable but a little
questionable while the Y log seemed totally wrong.

Here is one more thing to try so that we can get some needed
information.  Hopefully, your distribution auto-mounts the
/sys/kernel/debug filesystem.  If not, you can google and see how to
mount that.

One of your earlier lsusb outputs showed that your device is on USB
bus #2 and is device 008 on that bus.  If you move things around, it
can change so verify that is still true for next steps.

Bus 002 Device 008: ID 0b05:179f ASUSTek Computer, Inc.

You can log packets coming from USB bus #2 by running this as root:

cat /sys/kernel/debug/usb/usbmon/2u | tee /tmp/usb2.log

The pipe part is optional but I like to do that so I can see and log
whats going on.

If you have a lot of devices on that bus then the output could be
noisy.  You can usually filter the output to just your device #008
with grep:

cat /sys/kernel/debug/usb/usbmon/2u | grep 2:008 | /tmp/usb2.log

The lines that say Ii:2:008 are interrupt packets coming from
hardware.  When you put pen on screen, you should see a burst of them.
 Can you send a few of those?

Then we can see if if can reverse engineer the packet format.

Chris

--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev

Re: [Linuxwacom-devel] linuxwacom project - asustek eeenote tablet

[Chris Bagwell]

 (Pressure)
   Value  0
   Min    0
   Max  255
 Testing ... (interrupt to exit)

 Effectively, evtest doesn't report nothing when moving pen on tablet, but it
 does on console only mode.

Can you send the output from console mode?  Do the X/Y values seem to
make sense?  For example, drawing from top of screen to bottom of
screen do you see mostly only Y axis change values linearly?




 ### lsusb with module unload :

 [root@hpm mike]# lsusb -vvv -d 0b05:179f


OK.  Good info in this lsusb.  I'm not positive yet if this is a Wacom.

Pros: It does use a Report ID of 2 for pen packets and has a Feature
Report #2 as well that wacom driver likes to control on tablet PC's.

Cons: My math comes up with only 5 bytes declared for pen packet while
wacom driver expects it to be size 8.

Additional Pros: Sometimes thats what the Feature Report #2 is.  It
turns on a more advanced Pen Packet mode which I guess could cause it
to become bigger than size reported by HID report... but I'm not sure
of this for Tablet PC's.

Chris


 Bus 002 Device 008: ID 0b05:179f ASUSTek Computer, Inc.
 Device Descriptor:
   bLength    18
   bDescriptorType 1
   bcdUSB   1.10
   bDeviceClass    0 (Defined at Interface level)
   bDeviceSubClass 0
   bDeviceProtocol 0
   bMaxPacketSize0    16
   idVendor   0x0b05 ASUSTek Computer, Inc.
   idProduct  0x179f
   bcdDevice    1.29
   iManufacturer   1 ASUSTek Computer, Inc.
   iProduct    2 Eee Note Digitizer
   iSerial 3 1
   bNumConfigurations  1
   Configuration Descriptor:
     bLength 9
     bDescriptorType 2
     wTotalLength   34
     bNumInterfaces  1
     bConfigurationValue 1
     iConfiguration  4 pen report data
     bmAttributes 0xc0
   Self Powered
     MaxPower    2mA
     Interface Descriptor:
   bLength 9
   bDescriptorType 4
   bInterfaceNumber    0
   bAlternateSetting   0
   bNumEndpoints   1
   bInterfaceClass 3 Human Interface Device
   bInterfaceSubClass  0 No Subclass
   bInterfaceProtocol  2 Mouse
   iInterface  4 pen report data
     HID Device Descriptor:
   bLength 9
   bDescriptorType    33
   bcdHID   1.10
   bCountryCode   33 US
   bNumDescriptors 1
   bDescriptorType    34 Report
   wDescriptorLength 201
   Report Descriptor: (length is 201)
     Item(Global): Usage Page, data= [ 0x01 ] 1
     Generic Desktop Controls
     Item(Local ): Usage, data= [ 0x02 ] 2
     Mouse
     Item(Main  ): Collection, data= [ 0x01 ] 1
     Application
     Item(Global): Report ID, data= [ 0x01 ] 1
     Item(Local ): Usage, data= [ 0x01 ] 1
     Pointer
     Item(Main  ): Collection, data= [ 0x00 ] 0
     Physical
     Item(Global): Usage Page, data= [ 0x09 ] 9
     Buttons
     Item(Local ): Usage Minimum, data= [ 0x01 ] 1
     Button 1 (Primary)
     Item(Local ): Usage Maximum, data= [ 0x03 ] 3
     Button 3 (Tertiary)
     Item(Global): Logical Minimum, data= [ 0x00 ] 0
     Item(Global): Logical Maximum, data= [ 0x01 ] 1
     Item(Global): Report Count, data= [ 0x03 ] 3
     Item(Global): Report Size, data= [ 0x01 ] 1
     Item(Main  ): Input, data= [ 0x02 ] 2
     Data Variable Absolute No_Wrap Linear
     Preferred_State No_Null_Position Non_Volatile
 Bitfield
     Item(Global): Report Count, data= [ 0x01 ] 1
     Item(Global): Report Size, data= [ 0x05 ] 5
     Item(Main  ): Input, data= [ 0x01 ] 1
     Constant Array Absolute No_Wrap Linear
     Preferred_State No_Null_Position Non_Volatile
 Bitfield
     Item(Global): Usage Page, data= [ 0x01 ] 1
     Generic Desktop Controls
     Item(Local ): Usage, data= [ 0x30 ] 48
     Direction-X
     Item(Local ): Usage, data= [ 0x31 ] 49
     Direction-Y
     Item(Local ): Usage, data= [ 0x38 ] 56
     Wheel
     Item(Global): Logical Minimum, data= [ 0x81 ] 129
     Item(Global): Logical Maximum, data= [ 0x7f ] 127
     Item(Global): Report Size, data= [ 0x08 ] 8
     Item(Global): Report Count, data= [ 0x03 ] 3
     Item(Main  ): Input, data= [ 0x06 ] 6
     Data Variable Relative

Re: [Linuxwacom-devel] linuxwacom project - asustek eeenote tablet

[Chris Bagwell]

To speed your testing out, here is an alternative to try.

In case this is a non-wacom digitizer or even if is a wacom digitizer
but you'd like to use it in HID-compliant mode they sometimes have,
you can try to get HID core to work with it in correct mode.

As I mentioned in earlier email, the issue is that a mouse and a
digitizer is being combined into a single input device.  You can add a
quirk to hid-core for your device that will break them into 2
devices.

To do this, revert all your wacom_wac changes and your hid-core changes.

Instead edit the file linux/drivers/hid/usbhid/hid-quirks.c.
Copypaste a line that has the HID_QUIRK_MULTI_INPUT and replace its
VID/PID with your digitizer values.  Here is an example of such lines.

{ USB_VENDOR_ID_PLAYDOTCOM,
USB_DEVICE_ID_PLAYDOTCOM_EMS_USBII, HID_QUIRK_MULTI_INPUT },

This HID-compliant device will not work with xf86-input-wacom though.
You will also need to revert and xorg.conf files so that the device is
correctly matched to xf86-input-evdev.

Chris

On Mon, Jan 2, 2012 at 11:10 AM, Chris Bagwell ch...@cnpbagwell.com wrote:
 On Mon, Jan 2, 2012 at 3:13 AM, Mike Rolland none...@gmail.com wrote:
 Ok, let's dance for all your demands.
 Nevertheless, there's no pen click or move events on screen in normal mode.

 ### kernel diff :

 Index: drivers/input/tablet/wacom.h
 ===
 --- drivers/input/tablet/wacom.h
 +++ drivers/input/tablet/wacom.h 2011-12-31 19:19:08.452177869 +0400

 @@ -104,6 +104,7 @@

 #define USB_VENDOR_ID_WACOM 0x056a
 #define USB_VENDOR_ID_LENOVO 0x17ef
 +#define USB_VENDOR_ID_ASUSTEK 0x0b05



 struct wacom {
 Index: drivers/input/tablet/wacom_wac.c
 ===
 --- drivers/input/tablet/wacom_wac.c
 +++ drivers/input/tablet/wacom_wac.c 2011-12-31 12:31:10.224185924 +0400
 @@ -1503,6 +1503,9 @@
 static const struct wacom_features wacom_features_0x6004 =
 { ISD-V4,   WACOM_PKGLEN_GRAPHIRE,  12800,  8000,  255,
   0, TABLETPC, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
 +static const struct wacom_features wacom_features_0x179F =
 + { ISD-V4,   WACOM_PKGLEN_GRAPHIRE,  12800,  8000,  255,

 +   0, TABLETPC, WACOM_INTUOS_RES, WACOM_INTUOS_RES };

 #define USB_DEVICE_WACOM(prod) \
 USB_DEVICE(USB_VENDOR_ID_WACOM, prod), \
 @@ -1517,6 +1520,10 @@
 USB_DEVICE(USB_VENDOR_ID_LENOVO, prod), \
 .driver_info = (kernel_ulong_t)wacom_features_##prod

 +#define USB_DEVICE_ASUSTEK(prod) \
 + USB_DEVICE(USB_VENDOR_ID_ASUSTEK, prod), \

 + .driver_info = (kernel_ulong_t)wacom_features_##prod
 +
 const struct usb_device_id wacom_ids[] = {
 { USB_DEVICE_WACOM(0x00) },
 { USB_DEVICE_WACOM(0x10) },
 @@ -1607,6 +1614,7 @@
 { USB_DEVICE_WACOM(0xE6) },
 { USB_DEVICE_WACOM(0x47) },
 { USB_DEVICE_LENOVO(0x6004) },
 + { USB_DEVICE_ASUSTEK(0x179F) },
 { }
 };
 MODULE_DEVICE_TABLE(usb, wacom_ids);

 ### xf86 diff : (I place back in wcwUSB to 2450, 2540 )

 All of your X changes are not needed and could cause harm; especially
 if you mismark it as a Protocol 5 device. I would remove them to be
 safe.

 More info in case your interested on protocol:

 http://sourceforge.net/apps/mediawiki/linuxwacom/index.php?title=Wacom_Protocol_Overview



 Index: wcmUSB.c
 ===
 --- wcmUSB.c
 +++ wcmUSB.c 2012-01-02 01:03:03.050073315 +0400
 @@ -284,7 +284,10 @@
 { WALTOP_VENDOR_ID, 0x27,  8,  8, usbGraphire3  },
 { WALTOP_VENDOR_ID, 0x28,  8,  8, usbGraphire3  },
 { WALTOP_VENDOR_ID, 0x30,  8,  8, usbGraphire4  },
 - { WALTOP_VENDOR_ID, 0x31,  8,  8, usbGraphire4  },
 + /* WALTOP original strings */
 + /*{ WALTOP_VENDOR_ID, 0x31,  8,  8, usbGraphire4  }, */
 + /* WALTOP exprimental strings (medio 85837) */
 + { WALTOP_VENDOR_ID, 0x31, 20, 20, usbIntuos4  },
 { WALTOP_VENDOR_ID, 0x32, 10, 10, usbBambooFun  },
 { WALTOP_VENDOR_ID, 0x33, 10, 10, usbBambooFun  },
 { WALTOP_VENDOR_ID, 0x34,  8,  8, usbBamboo1    },
 @@ -308,10 +311,12 @@
 { WALTOP_VENDOR_ID, 0x503, 20, 20, usbIntuos4   },

 /* N-Trig devices */
 - { NTRIG_VENDOR_ID,  0x01, 44173, 36772, usbTabletPC    },
 + { NTRIG_VENDOR_ID,  0x01, 44173, 36772, usbTabletPC },

 /* Add in Lenovo W700 Palmrest digitizer */
 - { LENOVO_VENDOR_ID, 0x6004, 2540, 2540, usbTabletPC   } /* Pen-only */
 + { LENOVO_VENDOR_ID, 0x6004, 2540, 2540, usbTabletPC }, /* Pen-only */
 + /* ASUSTek EeeNote digitizer (experimental) */
 + { ASUSTEK_VENDOR_ID, 0x179f, 2540, 2540, usbTabletPC }
 };

 static Bool usbWcmInit(InputInfoPtr pInfo, char* id, float *version)
 Index: xf86Wacom.c
 ===
 --- xf86Wacom.c
 +++ xf86Wacom.c 2011-12-30 12:31:02.932275049 +0400
 @@ -494,6 +494,7 @@
 case WALTOP_VENDOR_ID:
 case HANWANG_VENDOR_ID:
 case LENOVO_VENDOR_ID:
 + case ASUSTEK_VENDOR_ID:
 return TRUE;
 default

Re: [Linuxwacom-devel] [PATCH 2/4 v2] Fix cursor jumping after zoom and scroll gestures when in Relative mode.

[Chris Bagwell]

I've one comment below but other than that:

Reviewed-by: Chris Bagwell ch...@cnpbagwell.com

If you make the modification suggested below, you can include my tag
in the next revision.

Chris

On Mon, Jan 2, 2012 at 11:58 AM, Alexey Osipov si...@lerlan.ru wrote:
 When touchpad is in Relative mode of operation, we need allow driver
 update internal old{x,y,z} variables to eliminate cursor jump after
 gesture ended. That update performed in wcmSendEvents() function in
 wcmCommon.c. So, when we in gesture mode, allow call wcmSendEvents()
 to update variables, but don't allow actual events sending to X server.

 Unnecessary axes modification removed from wcmSendButtonClick() in
 wcmTouchFilter.c, which was causing cursor movement in Absolute mode
 while gestures are active with respect to above changes.

 Signed-off-by: Alexey Osipov si...@lerlan.ru
 ---

 Changes to previous version (in reply to Chris Bagwell review):
 - check for wcmGestureMode moved from two places to one.
 - first change brakes absolute mode, which is fixed by removing
  unnecessary code from wcmSendButtonClick().

  src/wcmCommon.c      |   11 +--
  src/wcmTouchFilter.c |   10 +-
  2 files changed, 6 insertions(+), 15 deletions(-)

 diff --git a/src/wcmCommon.c b/src/wcmCommon.c
 index 21afcc5..10a154c 100644
 --- a/src/wcmCommon.c
 +++ b/src/wcmCommon.c
 @@ -810,8 +810,11 @@ void wcmSendEvents(InputInfoPtr pInfo, const 
 WacomDeviceState* ds)

        if (type == PAD_ID)
                wcmSendPadEvents(pInfo, ds, 3, priv-naxes - 3, 
 valuators[3]); /* pad doesn't post x/y/z */
 -       else
 -               wcmSendNonPadEvents(pInfo, ds, 0, priv-naxes, valuators);
 +       else {
 +               /* don't move the cursor if in gesture mode */
 +               if (!priv-common-wcmGestureMode)
 +                       wcmSendNonPadEvents(pInfo, ds, 0, priv-naxes, 
 valuators);
 +       }

        priv-oldProximity = ds-proximity;
        if (ds-proximity)
 @@ -1008,10 +1011,6 @@ void wcmEvent(WacomCommonPtr common, unsigned int 
 channel,
        if ((ds.device_type == TOUCH_ID)  common-wcmTouch)
                wcmGestureFilter(priv, channel);

 -       /* don't move the cursor if in gesture mode */
 -       if (common-wcmGestureMode)
 -               return;
 -
        /* For touch, only first finger moves the cursor */
        if ((ds.device_type == TOUCH_ID  common-wcmTouch  !channel) ||
            (ds.device_type != TOUCH_ID))
 diff --git a/src/wcmTouchFilter.c b/src/wcmTouchFilter.c
 index 047490b..7f9f4f2 100644
 --- a/src/wcmTouchFilter.c
 +++ b/src/wcmTouchFilter.c
 @@ -93,19 +93,11 @@ static Bool pointsInLine(WacomCommonPtr common, 
 WacomDeviceState ds0,
  /* send a button event */
  static void wcmSendButtonClick(WacomDevicePtr priv, int button, int state)
  {
 -       int x = 0;
 -       int y = 0;
        int mode = is_absolute(priv-pInfo);

 -       if (mode)
 -       {
 -               x = priv-oldX;
 -               y = priv-oldY;
 -       }
 -
        /* send button event in state */
        xf86PostButtonEvent(priv-pInfo-dev, mode,button,
 -               state,0,priv-naxes,x,y,0,0,0,0);
 +               state,0,0);

Great job tracking down exact source causing absolute mode the issue.
This is a good chance to have on its own.

I hope Ping or Peter will be able to comment on this though.  I think
there is some historical bug in X server for xf86PostButtonEvent()
that doesn't support 0 axis and probably why its written as it was.  I
believe the bug never existed in xf86PostButtonEventP() and seems to
be the preferred interface now anyways (wcmCommon.c was changed to use
only that over the last year or so).

To be safe, you can switch to it by adding a P to end of Event in
above line and adding an extra ,0 before ).


        /* We have changed the button state (from down to up) for the device
         * so we need to update the record */
 --
 1.7.0.4




--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH 2/4] Fix cursor jumping after zoom and scroll gestures when in Relative mode.

[Chris Bagwell]

On Sat, Dec 31, 2011 at 1:58 AM, Alexey Osipov si...@lerlan.ru wrote:
 В Птн, 30/12/2011 в 13:30 -0600, Chris Bagwell пишет:
 The need for this makes sense (although I haven't tested it to much to
 see the jump).

 Although absolute devices don't have the same delta issue, I think its
 better to use same code flow in both cases.  So I'd totally delete the
 original if (wcmGestureMode) return; and add the single if() inside
 wcmSendEvents().

 Just tried to do what you have suggested. In that case we have broken
 (in same way) Absolute mode for touch device. E.g. cursor jumps to wrong
 position just after any gesture has been used, but for Absolute mode.

Really?  Oh well.

I would really like to keep the gesture specific logic close together
in wcmCommon.c so we don't have to dig around so hard for differences
or introduce unneeded behaviour differences between modes.

How about we move the original if() to top of wcmSendEvents() instead
of wcEvents()?  I think thats still early enough to prevent a jump.

Chris


 I'd also limit the wcmGestureMode to wcmSendNonPadEvents() since PAD
 devices never have gestures.

 Look reasonable. If no more comments on this patch, I'll repost a new
 version with this only modification soon.


 Chris

 On Sat, Dec 24, 2011 at 12:18 AM, Alexey Osipov si...@lerlan.ru wrote:
  When touchpad is in Relative mode of operation, we need allow driver
  update internal old{x,y,z} variables to eliminate cursor jump after
  gesture ended. That update performed in wcmSendEvents() function in
  wcmCommon.c. So, when we in relative mode, allow call wcmSendEvents()
  to update variables, but don't allow actual events sending to X server.
 
  Signed-off-by: Alexey Osipov si...@lerlan.ru
  ---
   src/wcmCommon.c |   13 -
   1 files changed, 8 insertions(+), 5 deletions(-)
 
  diff --git a/src/wcmCommon.c b/src/wcmCommon.c
  index e85c6d8..d0bff63 100644
  --- a/src/wcmCommon.c
  +++ b/src/wcmCommon.c
  @@ -743,10 +743,13 @@ void wcmSendEvents(InputInfoPtr pInfo, const 
  WacomDeviceState* ds)
         valuators[4] = v4;
         valuators[5] = v5;
 
  -       if (type == PAD_ID)
  -               wcmSendPadEvents(pInfo, ds, 3, 3, valuators[3]); /* pad 
  doesn't post x/y/z */
  -       else
  -               wcmSendNonPadEvents(pInfo, ds, 0, priv-naxes, valuators);
  +       /* don't move the cursor if in gesture mode */
  +       if (!(!is_absolute(pInfo)  priv-common-wcmGestureMode)) {
  +               if (type == PAD_ID)
  +                       wcmSendPadEvents(pInfo, ds, 3, 3, valuators[3]); 
  /* pad doesn't post x/y/z */
  +               else
  +                       wcmSendNonPadEvents(pInfo, ds, 0, priv-naxes, 
  valuators);
  +       }
 
         priv-oldProximity = ds-proximity;
         if (ds-proximity)
  @@ -943,7 +946,7 @@ void wcmEvent(WacomCommonPtr common, unsigned int 
  channel,
                 wcmGestureFilter(priv, channel);
 
         /* don't move the cursor if in gesture mode */
  -       if (common-wcmGestureMode)
  +       if ((priv-flags  ABSOLUTE_FLAG)  (common-wcmGestureMode))
                 return;
 
         /* For touch, only first finger moves the cursor */
  --
  1.7.0.4
 
 
 
 
  --
  Write once. Port to many.
  Get the SDK and tools to simplify cross-platform app development. Create
  new or port existing apps to sell to consumers worldwide. Explore the
  Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
  http://p.sf.net/sfu/intel-appdev
  ___
  Linuxwacom-devel mailing list
  Linuxwacom-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel



--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH 3/4] 'Left mouse button' dragging support.

[Chris Bagwell]

On Sat, Dec 31, 2011 at 2:16 AM, Alexey Osipov si...@lerlan.ru wrote:
 В Птн, 30/12/2011 в 13:54 -0600, Chris Bagwell пишет:
 I'm glad someone decided to add this!  I wanted to but been to busy.

 Similar to Peter's past comments on the file wcmTouchFilter.c, this
 code is almost obsolete before being published and so I'm not
 reviewing very strict.

 Could you please point me to that Perer's comment? I'm not quite
 understand what you are meaning.

I'm referring to comment Peter made when he first submitting the patch
for wcmTouchFilter.c to xf86-input-wacom.  Its not real important but
I just wanted to qualify changes to this file aren't as strict in my
opinion.


 Comments below.

 On Sat, Dec 24, 2011 at 12:18 AM, Alexey Osipov si...@lerlan.ru wrote:
  First, we define two new GESTURE_ modes:
  - GESTURE_PREDRAG_MODE - when first tap happen and we wait for second 
  touch.
  - GESTURE_DRAG_MODE -  when actual drag happening (left button pressed).
 
  Second, we define tap timeout function wcmSingleFingerTapTimer(), which
  simulate single click if no drag operation started within timeout.
 
  Third, we make an exception for GESTURE_DRAG_MODE in wcmCommon.c, because
  we actually want cursor movements while dragging.
 
  Now, to do a single tap you just tap (touch and untouch). Actual click
  happens after TapTime period.
  To drag something you make a tap (touch and untouch) and then quickly
  (in TapTime period) touch device again. Then drag.
 
  Signed-off-by: Alexey Osipov si...@lerlan.ru
  ---
   src/common.mk        |    3 +-
   src/wcmCommon.c      |    8 +++---
   src/wcmTouchFilter.c |   54 
  -
   src/wcmTouchFilter.h |   38 +++
   src/xf86Wacom.h      |    1 -
   5 files changed, 88 insertions(+), 16 deletions(-)
   create mode 100644 src/wcmTouchFilter.h
 
  diff --git a/src/common.mk b/src/common.mk
  index fae8d9f..7f1eadd 100644
  --- a/src/common.mk
  +++ b/src/common.mk
  @@ -12,4 +12,5 @@ DRIVER_SOURCES= \
         $(top_srcdir)/src/wcmUSB.c \
         $(top_srcdir)/src/wcmXCommand.c \
         $(top_srcdir)/src/wcmValidateDevice.c \
  -       $(top_srcdir)/src/wcmTouchFilter.c
  +       $(top_srcdir)/src/wcmTouchFilter.c \
  +       $(top_srcdir)/src/wcmTouchFilter.h
  diff --git a/src/wcmCommon.c b/src/wcmCommon.c
  index d0bff63..0cab803 100644
  --- a/src/wcmCommon.c
  +++ b/src/wcmCommon.c
  @@ -24,6 +24,7 @@
   #include xf86Wacom.h
   #include Xwacom.h
   #include wcmFilter.h
  +#include wcmTouchFilter.h
   #include xkbsrv.h
   #include xf86_OSproc.h
 
  @@ -743,8 +744,8 @@ void wcmSendEvents(InputInfoPtr pInfo, const 
  WacomDeviceState* ds)
         valuators[4] = v4;
         valuators[5] = v5;
 
  -       /* don't move the cursor if in gesture mode */
  -       if (!(!is_absolute(pInfo)  priv-common-wcmGestureMode)) {
  +       /* don't move the cursor if in gesture mode (except drag mode) */
  +       if (!(!is_absolute(pInfo)  priv-common-wcmGestureMode  
  ~GESTURE_DRAG_MODE)) {
                 if (type == PAD_ID)
                         wcmSendPadEvents(pInfo, ds, 3, 3, valuators[3]); 
  /* pad doesn't post x/y/z */
                 else
  @@ -945,8 +946,7 @@ void wcmEvent(WacomCommonPtr common, unsigned int 
  channel,
         if ((ds.device_type == TOUCH_ID)  common-wcmTouch)
                 wcmGestureFilter(priv, channel);
 
  -       /* don't move the cursor if in gesture mode */
  -       if ((priv-flags  ABSOLUTE_FLAG)  (common-wcmGestureMode))
  +       if ((priv-flags  ABSOLUTE_FLAG)  (common-wcmGestureMode  
  ~GESTURE_DRAG_MODE))
                 return;

 These would need to align with comment on previous patch.

 Agreed.

 And more a personal opinion, I think the wcmGestureMode values are
 meant to be more internal to the touch filter engine and shouldn't be
 exposed to wcmCommon.c.  I'd prefer if you exported a new function
 with name like wcmTouchNeedsFilter() that returns yes/no answer and
 then you add exact values to check inside wcmTouchFilter.c.

 Yes, this can be done that way. But isn't calling extra function will
 slow down overall events processing? I don't think that extra CPU usage
 in driver is a good idea. What you think?

No, function calls are good in driver to improve readability. We do
this quite often. In this case, there is 99% chance that compiler will
inline the function anyways.


 
         /* For touch, only first finger moves the cursor */
  diff --git a/src/wcmTouchFilter.c b/src/wcmTouchFilter.c
  index 047490b..c1a6071 100644
  --- a/src/wcmTouchFilter.c
  +++ b/src/wcmTouchFilter.c
  @@ -1,5 +1,6 @@
   /*
   * Copyright 2009 - 2010 by Ping Cheng, Wacom. pi...@wacom.com
  + * Copyright 2011 by Alexey Osipov. si...@lerlan.ru
   *
   * This program is free software; you can redistribute it and/or
   * modify it under the terms of the GNU General Public License
  @@ -21,6 +22,7 @@
   #endif
 
   #include xf86Wacom.h
  +#include wcmTouchFilter.h

Re: [Linuxwacom-devel] linuxwacom project - asustek eeenote tablet

[Chris Bagwell]

On Sat, Dec 31, 2011 at 2:51 AM, Mike Rolland none...@gmail.com wrote:
 Ok, this evterst main display:
 I attach full log in file.

 [root@hpm mike]# evtest /dev/input/event14
 Input driver version is 1.0.1
 Input device ID: bus 0x3 vendor 0xb05 product 0x179f version 0x110
 Input device name: ASUSTek Computer, Inc. Eee Note Digitizer
 Supported events:
   Event type 0 (Sync)
   Event type 1 (Key)
     Event code 272 (LeftBtn)
     Event code 273 (RightBtn)
     Event code 274 (MiddleBtn)
     Event code 330 (Touch)
   Event type 2 (Relative)
     Event code 0 (X)
     Event code 1 (Y)
     Event code 8 (Wheel)

Yes, this is the part that shows why its not working out of the box.
Having both relative and absolute X/Y events will confuse
xf86-input-evdev into making your touchscreen act like a touchpad.

Also, there is no PEN/STYLUS described which may or may not confuse
xf86-input-wacom (I forget were we are at there.  I tried to make it
optional but do not remember if I was successful).

This proves you'll have to get a custom kernel driver handling this
device before it will work with xf86-input-*.

Chris

   Event type 3 (Absolute)
     Event code 0 (X)
   Value  0
   Min    0
   Max    16480
     Event code 1 (Y)
   Value  0
   Min    0
   Max    12410
     Event code 24 (Pressure)
   Value  0
   Min    0
   Max  255
   Event type 4 (Misc)
     Event code 4 (ScanCode)
 Testing ... (interrupt to exit)

 Le vendredi 30 décembre 2011 à 16:45 -0600, Chris Bagwell a écrit :

 On Fri, Dec 30, 2011 at 2:21 PM, Mike Rolland none...@gmail.com wrote:
 Le vendredi 30 décembre 2011 à 11:37 -0600, Chris Bagwell a écrit :

  * Run dmesg | grep ASUSTek and look for line telling if kernel
 driver has been installed for this device.

 [root@hpm mike]# dmesg | grep ASUSTek
 usb 2-1.2: Manufacturer: ASUSTek Computer, Inc.
 input: ASUSTek Computer, Inc. Eee Note Digitizer as
 /devices/pci:00/:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/input/input14
 generic-usb 0003:0B05:179F.0002: input,hiddev0,hidraw1: USB HID v1.10
 Mouse
 [ASUSTek Computer, Inc. Eee Note Digitizer] on usb-:00:1d.0-1.2/input0

 OK, this is the part I want to concentrate on.  That USB HID v1.10
 Mouse part means its probably being reported to userland as a strange
 mouse+pen combo device.  Its related to the HID report for digitizer
 declaring a mouse (required by Microsoft for tabletPC's I think even
 if its not really used).

 To better see what kernel is doing, you'll need to install the
 evtest app from your distro's repo.  Run it as root and from a
 console (not from X) or it will hide some stuff from you.

 evtest /dev/input/eventtX  --- The value for X is usually found from
 trail and error.

 Please send what this displays.  You can pipe to a file as well
 (evtest /dev/input/eventX  log).


 I googled for this USB ID and got one result where it said its being
 detected as a generic HID Mouse.  This would not be a good thing and
 all your work in xf86-input-wacom or xf86-input-evdev will be in vain
 until kernel side issue is resolved.

 Not really sure about that.
 Often the problem comes only from XF86 driver, but like I told to Favux, I
 will have a look to wacom dev kernel libs. The first time I made my
 homebrew
 with my WALTOP tablet, I remember I change something in kernel driver.
 So...

 In last year, I think problem areas have moved.  xf86-input-wacom and
 xf86-input-evdev have become quite stable for new
 digitizers/tabletPC's and touchscreens without modifications.  The
 issues are almost always in kernel now for new hardware.

 I see people go to great lengths though to hack up xf86-input-*
 instead of fixing the real kernel side issue and try to ignore that
 invalid mouse information.

 When we see the mouse+touchscreen issue in recent times, the cure is
 to get the hid-multitouch driver to control the touchscreen.

 In your case, its a mouse+pen so I'm not sure what driver its supposed
 to be routed to.  If the Asus web page that Favux is to be trusted,
 its a Wacom digitizer and so maybe it should be handled by wacom
 driver.  I have seen Wacom commonly use 0x81 as Endpoint address for
 PEN's so thats a good sign.

 I'd try the hint given by Favux and update the file wacom_wac.c from
 input-wacom package to understand Eee product ID's.

 Chris



--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] linuxwacom project - asustek eeenote tablet

[Chris Bagwell]

On Fri, Dec 30, 2011 at 10:17 AM, Favux ... favux...@gmail.com wrote:
 Hi Mike,

 Is this the Eee Note EA800?  An e-ink e-book reader with an active
 stylus with 256 pressure levels and no touch?
 http://www.asus.com/Eee/Eee_Note/Eee_Note_EA800/

 If so it apparently is a Wacom digitizer.  But there is no Wacom
 digitizer in the lsusb output?  Just the Bus 002 Device 012: ID
 0b05:179f ASUSTek Computer, Inc.?

 To get it working the first thing you would probably need to do is add
 it to the wacom.ko.  Using input-wacom would probably be more
 convenient than working with your kernel.  We'll need to see what the
 experts say but something along the lines of adding the ASUSTek Vendor
 ID like the Lenovo ID was added to, for example, wacom.h and
 wacom_wac.c.  Although the apparent digitizer is given an Asus product
 ID, which doesn't follow Wacom conventions, I wouldn't be surprised if
 it is in fact a Wacom (tabletPC?) digitizer already entered.

 What is your Distribution and release?  Kernel, Xorg, and
 xf86-input-wacom versions?

 Could you attach the output of:
    lsusb 
 for the digitizer to your next post?

 Favux


I have two additional requests.

 * Please run lsusb -vvv as root.  This is only way to get the full
HID report.  I believe this does not always work if a kernel input
driver has latched onto the device.
 * Run dmesg | grep ASUSTek and look for line telling if kernel
driver has been installed for this device.

I googled for this USB ID and got one result where it said its being
detected as a generic HID Mouse.  This would not be a good thing and
all your work in xf86-input-wacom or xf86-input-evdev will be in vain
until kernel side issue is resolved.

Chris

Chris

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH 1/4] Extra right clicks removed.

[Chris Bagwell]

I had wanted to change 2nd-finger tap gesture to a 2 finger tap (the
difference being that in former you leave 1st finger touching and in
later you tap both fingers and release both fingers).

But I may never get around to that since gestures are moving outside X
soon enough.

So in mean time, this patch looks good to remove chance of second
unwanted click.

Reviewed-by: Chris Bagwell ch...@cnpbagwell.com

Chris

On Sat, Dec 24, 2011 at 12:18 AM, Alexey Osipov si...@lerlan.ru wrote:
 As right click performed with second finger, then we only interested
 in second finger touch when trying to match 'right click' gesture.

 Signed-off-by: Alexey Osipov si...@lerlan.ru
 ---
  src/wcmTouchFilter.c |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/src/wcmTouchFilter.c b/src/wcmTouchFilter.c
 index 7fa2975..047490b 100644
 --- a/src/wcmTouchFilter.c
 +++ b/src/wcmTouchFilter.c
 @@ -321,7 +321,7 @@ void wcmGestureFilter(WacomDevicePtr priv, int channel)
                goto ret;
        }

 -       if (!(common-wcmGestureMode  (GESTURE_SCROLL_MODE | 
 GESTURE_ZOOM_MODE)))
 +       if (!(common-wcmGestureMode  (GESTURE_SCROLL_MODE | 
 GESTURE_ZOOM_MODE))  channel)
                wcmFingerTapToClick(priv);

        /* Change mode happens only when both fingers are out */
 --
 1.7.0.4




 --
 Write once. Port to many.
 Get the SDK and tools to simplify cross-platform app development. Create
 new or port existing apps to sell to consumers worldwide. Explore the
 Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
 http://p.sf.net/sfu/intel-appdev
 ___
 Linuxwacom-devel mailing list
 Linuxwacom-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH 2/4] Fix cursor jumping after zoom and scroll gestures when in Relative mode.

[Chris Bagwell]

The need for this makes sense (although I haven't tested it to much to
see the jump).

Although absolute devices don't have the same delta issue, I think its
better to use same code flow in both cases.  So I'd totally delete the
original if (wcmGestureMode) return; and add the single if() inside
wcmSendEvents().

I'd also limit the wcmGestureMode to wcmSendNonPadEvents() since PAD
devices never have gestures.

Chris

On Sat, Dec 24, 2011 at 12:18 AM, Alexey Osipov si...@lerlan.ru wrote:
 When touchpad is in Relative mode of operation, we need allow driver
 update internal old{x,y,z} variables to eliminate cursor jump after
 gesture ended. That update performed in wcmSendEvents() function in
 wcmCommon.c. So, when we in relative mode, allow call wcmSendEvents()
 to update variables, but don't allow actual events sending to X server.

 Signed-off-by: Alexey Osipov si...@lerlan.ru
 ---
  src/wcmCommon.c |   13 -
  1 files changed, 8 insertions(+), 5 deletions(-)

 diff --git a/src/wcmCommon.c b/src/wcmCommon.c
 index e85c6d8..d0bff63 100644
 --- a/src/wcmCommon.c
 +++ b/src/wcmCommon.c
 @@ -743,10 +743,13 @@ void wcmSendEvents(InputInfoPtr pInfo, const 
 WacomDeviceState* ds)
        valuators[4] = v4;
        valuators[5] = v5;

 -       if (type == PAD_ID)
 -               wcmSendPadEvents(pInfo, ds, 3, 3, valuators[3]); /* pad 
 doesn't post x/y/z */
 -       else
 -               wcmSendNonPadEvents(pInfo, ds, 0, priv-naxes, valuators);
 +       /* don't move the cursor if in gesture mode */
 +       if (!(!is_absolute(pInfo)  priv-common-wcmGestureMode)) {
 +               if (type == PAD_ID)
 +                       wcmSendPadEvents(pInfo, ds, 3, 3, valuators[3]); /* 
 pad doesn't post x/y/z */
 +               else
 +                       wcmSendNonPadEvents(pInfo, ds, 0, priv-naxes, 
 valuators);
 +       }

        priv-oldProximity = ds-proximity;
        if (ds-proximity)
 @@ -943,7 +946,7 @@ void wcmEvent(WacomCommonPtr common, unsigned int channel,
                wcmGestureFilter(priv, channel);

        /* don't move the cursor if in gesture mode */
 -       if (common-wcmGestureMode)
 +       if ((priv-flags  ABSOLUTE_FLAG)  (common-wcmGestureMode))
                return;

        /* For touch, only first finger moves the cursor */
 --
 1.7.0.4




 --
 Write once. Port to many.
 Get the SDK and tools to simplify cross-platform app development. Create
 new or port existing apps to sell to consumers worldwide. Explore the
 Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
 http://p.sf.net/sfu/intel-appdev
 ___
 Linuxwacom-devel mailing list
 Linuxwacom-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] linuxwacom project - asustek eeenote tablet

[Chris Bagwell]

On Fri, Dec 30, 2011 at 2:21 PM, Mike Rolland none...@gmail.com wrote:
 Le vendredi 30 décembre 2011 à 11:37 -0600, Chris Bagwell a écrit :

  * Run dmesg | grep ASUSTek and look for line telling if kernel
 driver has been installed for this device.

 [root@hpm mike]# dmesg | grep ASUSTek
 usb 2-1.2: Manufacturer: ASUSTek Computer, Inc.
 input: ASUSTek Computer, Inc. Eee Note Digitizer as
 /devices/pci:00/:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/input/input14
 generic-usb 0003:0B05:179F.0002: input,hiddev0,hidraw1: USB HID v1.10 Mouse
 [ASUSTek Computer, Inc. Eee Note Digitizer] on usb-:00:1d.0-1.2/input0

OK, this is the part I want to concentrate on.  That USB HID v1.10
Mouse part means its probably being reported to userland as a strange
mouse+pen combo device.  Its related to the HID report for digitizer
declaring a mouse (required by Microsoft for tabletPC's I think even
if its not really used).

To better see what kernel is doing, you'll need to install the
evtest app from your distro's repo.  Run it as root and from a
console (not from X) or it will hide some stuff from you.

evtest /dev/input/eventtX  --- The value for X is usually found from
trail and error.

Please send what this displays.  You can pipe to a file as well
(evtest /dev/input/eventX  log).


 I googled for this USB ID and got one result where it said its being
 detected as a generic HID Mouse.  This would not be a good thing and
 all your work in xf86-input-wacom or xf86-input-evdev will be in vain
 until kernel side issue is resolved.

 Not really sure about that.
 Often the problem comes only from XF86 driver, but like I told to Favux, I
 will have a look to wacom dev kernel libs. The first time I made my homebrew
 with my WALTOP tablet, I remember I change something in kernel driver. So...

In last year, I think problem areas have moved.  xf86-input-wacom and
xf86-input-evdev have become quite stable for new
digitizers/tabletPC's and touchscreens without modifications.  The
issues are almost always in kernel now for new hardware.

I see people go to great lengths though to hack up xf86-input-*
instead of fixing the real kernel side issue and try to ignore that
invalid mouse information.

When we see the mouse+touchscreen issue in recent times, the cure is
to get the hid-multitouch driver to control the touchscreen.

In your case, its a mouse+pen so I'm not sure what driver its supposed
to be routed to.  If the Asus web page that Favux is to be trusted,
its a Wacom digitizer and so maybe it should be handled by wacom
driver.  I have seen Wacom commonly use 0x81 as Endpoint address for
PEN's so thats a good sign.

I'd try the hint given by Favux and update the file wacom_wac.c from
input-wacom package to understand Eee product ID's.

Chris

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] Soft buttons for wacom digitazer on HP TC4200

[Chris Bagwell]

On Fri, Dec 30, 2011 at 3:00 PM, Yaroslav Sheptykin
yarik.shepty...@googlemail.com wrote:
 Hi Wacom Experts!

        I am a happy owner of an old HP TC4200 tablet. Since last two
        years I have been using various versions of Ubuntu and none of
        recent brought full functionality to my wacom digitizer out of
        the ox (the last one got pretty close though). Different
        versions led me to different hacks to get stuff to work the way
        I want. One thing though always left outside of any
        configuration reach - the SOFT BUTTONS. I have 3 soft buttons
        available for the pen to press. They work great under windows
        but show no presence of life under ubuntu. Through a long trial
        of forum posts I came to a patch to your Xorg driver that was
        ought to solve the issue. I compiled and installed that but no
        success. Could you let me know if I am on the right path before
        I dig deep into the depth of driver's source and your developer
        documentation?

        Is it the resposibility of wacom-xorg driver to detect presses
        on those buttons?

        I attached some files and here is uname -a output

        Linux prime 3.0.0-14-generic #23-Ubuntu SMP Mon Nov 21 20:34:47
        UTC 2011 i686 i686 i386 GNU/Linux

        anything else?

 Thanks,

I'm guessing that your have a ISDV4 interface.  The following thread
is someone that added support for non-standard buttons on tablet
itself to ISDV4 logic.

http://www.mail-archive.com/linuxwacom-devel@lists.sourceforge.net/msg03370.html

I never saw the code committed to xf86-input-wacom or linux kernel.

Chris

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

[Linuxwacom-devel] [PATCH input-wacom] Add missing input_mt_get_value() for 2.6.36/37

[chris]

From: Chris Bagwell ch...@cnpbagwell.com

Reported in bug tracker #3463769.

Based on mini code review, I think this is only missing
symbol and 2.6.36/37 contain ABS_MT_FIRST and input_mt_slot
which this function depends on.

I'm unable to test this fix but its a copypaste of
function from mt.h in later kernels.
---
 2.6.36/wacom.h |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/2.6.36/wacom.h b/2.6.36/wacom.h
index 3117877..569ad9c 100644
--- a/2.6.36/wacom.h
+++ b/2.6.36/wacom.h
@@ -94,6 +94,12 @@
 # endif 
 #if LINUX_VERSION_CODE  KERNEL_VERSION(2,6,37)
 #include linux/input/mt.h
+#else
+static inline int input_mt_get_value(const struct input_mt_slot *slot,
+ unsigned code)
+{
+return slot-abs[code - ABS_MT_FIRST];
+}
 #endif
 #include asm/unaligned.h
 
-- 
1.7.7.4


--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel