Re: [Linuxwacom-devel] Intuos4 OLED icons

2012-03-29 Thread Jason Gerecke
On Thu, Mar 29, 2012 at 2:30 PM, Przemo Firszt  wrote:
> I want to test the kernel part for modyfing OLED icons and the LED
> indicator. Is there anything in the userland that I could use for it?
>
> The only thing that I managed to find is this [1], but it doesn't seems
> to use the kernel architecture form wacom drivers. Instead it talks
> directly to USB (I might be wrong on that).
>
> [1]
> http://www.davidrevoy.com/index.php?article70/set-the-led-display-of-the-wacom-intuos4-tablet-on-ubuntu-linuxmint
>
> --
> Przemo Firszt
>
>

LED indicator lights are easy -- you can just echo a number
representing the LED# you want to light into the appropriate sysfs
node:

# cd /sys//wacom_led
# echo -n 1 > status_led0_select

I'm not sure about the OLEDs though. I think there's a something out
there, but I didn't find anything after quickly scanning my archive of
this list... Hopefully somebody else has an idea :)

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

2012-03-29 Thread Jason Gerecke
I've been meaning to get around to reviewing your patch (I'm glad to
see you taking it on!), but have been pretty busy lately. Sorry for
the delay...

On Thu, Mar 22, 2012 at 12:37 PM, Nikolai Kondrashov  wrote:
> Use tilt range and, optionally, resolution reported by the kernel for event
> devices.
>
> Temporarily center the range on zero until kernel is fixed to do this.
>
> Use resolution, if present, to determine the physical range and clamp/extend
> it to 60 degrees either way as expected by applications, otherwise assume it
> corresponds to this range.
>
> This is needed to handle non-Wacom tablets reporting zero-centered tilt and
> having physical range greater than 60 degrees.
> ---
>
> This is in continuation of the "Tilt value meaning" thread:
> http://sf.net/mailarchive/forum.php?thread_name=4F5F6C72.8080906%40gmail.com&forum_name=linuxwacom-devel
>
> This is needed to support Waltop Sirius Battery Free Tablet patches:
> http://thread.gmane.org/gmane.linux.kernel.input/24153
>
>  src/wcmCommon.c     |    8 -
>  src/wcmFilter.c     |   16 +-
>  src/wcmISDV4.c      |   12 +++-
>  src/wcmUSB.c        |   74 +-
>  src/xf86Wacom.c     |    8 +++---
>  src/xf86WacomDefs.h |   11 ++-
>  6 files changed, 109 insertions(+), 20 deletions(-)
>
> diff --git a/src/wcmCommon.c b/src/wcmCommon.c
> index 7199105..1d66209 100644
> --- a/src/wcmCommon.c
> +++ b/src/wcmCommon.c
> @@ -1466,8 +1466,12 @@ WacomCommonPtr wcmNewCommon(void)
>        common->wcmMaxTouchY = 1024;       /* max touch Y value */
>        common->wcmMaxStripX = 4096;       /* Max fingerstrip X */
>        common->wcmMaxStripY = 4096;       /* Max fingerstrip Y */
> -       common->wcmMaxtiltX = 128;         /* Max tilt in X directory */
> -       common->wcmMaxtiltY = 128;         /* Max tilt in Y directory */
> +       common->wcmTiltXOff = -64;         /* Tilt offset in X direction */
> +       common->wcmTiltXMin = -64;         /* Min tilt in X direction */
> +       common->wcmTiltXMax = 64;          /* Max tilt in X direction */
> +       common->wcmTiltYOff = -64;         /* Tilt offset in Y direction */
> +       common->wcmTiltYMin = -64;         /* Min tilt in Y direction */
> +       common->wcmTiltYMax = 64;          /* Max tilt in Y direction */

There's no need to initialize any of these variables here. Instead, they should
be initialized in usbWcmGetRanges.

>        common->wcmCursorProxoutDistDefault = PROXOUT_INTUOS_DISTANCE;
>                        /* default to Intuos */
>        common->wcmSuppress = DEFAULT_SUPPRESS;
> diff --git a/src/wcmFilter.c b/src/wcmFilter.c
> index 47e958a..3802857 100644
> --- a/src/wcmFilter.c
> +++ b/src/wcmFilter.c
> @@ -298,16 +298,16 @@ int wcmFilterCoord(WacomCommonPtr common, 
> WacomChannelPtr pChannel,
>                                    ds->device_type == ERASER_ID))
>        {
>                ds->tiltx = tx / common->wcmRawSample;
> -               if (ds->tiltx > common->wcmMaxtiltX/2-1)
> -                       ds->tiltx = common->wcmMaxtiltX/2-1;
> -               else if (ds->tiltx < -common->wcmMaxtiltX/2)
> -                       ds->tiltx = -common->wcmMaxtiltX/2;
> +               if (ds->tiltx > common->wcmTiltXMax)
> +                       ds->tiltx = common->wcmTiltXMax;
> +               else if (ds->tiltx < common->wcmTiltXMin)
> +                       ds->tiltx = common->wcmTiltXMin;
>
>                ds->tilty = ty / common->wcmRawSample;
> -               if (ds->tilty > common->wcmMaxtiltY/2-1)
> -                       ds->tilty = common->wcmMaxtiltY/2-1;
> -               else if (ds->tilty < -common->wcmMaxtiltY/2)
> -                       ds->tilty = -common->wcmMaxtiltY/2;
> +               if (ds->tilty > common->wcmTiltYMax)
> +                       ds->tilty = common->wcmTiltYMax;
> +               else if (ds->tilty < common->wcmTiltYMin)
> +                       ds->tilty = common->wcmTiltYMin;
>        }
>
>        return 0; /* lookin' good */

Why do we bother doing clamping in this function? git-blame indicates
that the behavior is as old as the driver, but I can't find any
compelling reason for keeping it around.

> diff --git a/src/wcmISDV4.c b/src/wcmISDV4.c
> index 892fbff..5aa68c5 100644
> --- a/src/wcmISDV4.c
> +++ b/src/wcmISDV4.c
> @@ -405,8 +405,16 @@ static int isdv4GetRanges(InputInfoPtr pInfo)
>                common->wcmMaxY = reply.y_max;
>                if (reply.tilt_x_max && reply.tilt_y_max)
>                {
> -                       common->wcmMaxtiltX = reply.tilt_x_max;
> -                       common->wcmMaxtiltY = reply.tilt_y_max;
> +                       common->wcmTiltXOff = -reply.tilt_x_max/2;
> +                       common->wcmTiltXMin = 0 + common->wcmTiltXOff;
> +                       common->wcmTiltXMax = reply.tilt_x_max +
> +                                             common->wcmTiltXOff;
> +
> +                       common->wcmTiltYO

[Linuxwacom-devel] Intuos4 OLED icons

2012-03-29 Thread Przemo Firszt
I want to test the kernel part for modyfing OLED icons and the LED
indicator. Is there anything in the userland that I could use for it?

The only thing that I managed to find is this [1], but it doesn't seems
to use the kernel architecture form wacom drivers. Instead it talks
directly to USB (I might be wrong on that).

[1]
http://www.davidrevoy.com/index.php?article70/set-the-led-display-of-the-wacom-intuos4-tablet-on-ubuntu-linuxmint

-- 
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 input-wacom 1/2] backport: add support for Cintiq 24HD

2012-03-29 Thread Chris Bagwell
On Thu, Mar 29, 2012 at 10:36 AM, Jason Gerecke  wrote:
> On Thu, Mar 29, 2012 at 6:54 AM, Chris Bagwell  wrote:
>> On Wed, Mar 28, 2012 at 12:31 PM, Ping Cheng  wrote:
>>> On Wed, Mar 28, 2012 at 9:29 AM, Jason Gerecke  wrote:
 Based on upstream commit 803296b678a43005e3bc0aaa1951d211bd76a054

 Signed-off-by: Jason Gerecke 
>>>
>>> Acked-by: Ping Cheng  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 input-wacom 1/2] backport: add support for Cintiq 24HD

2012-03-29 Thread Jason Gerecke
On Thu, Mar 29, 2012 at 6:54 AM, Chris Bagwell  wrote:
> On Wed, Mar 28, 2012 at 12:31 PM, Ping Cheng  wrote:
>> On Wed, Mar 28, 2012 at 9:29 AM, Jason Gerecke  wrote:
>>> Based on upstream commit 803296b678a43005e3bc0aaa1951d211bd76a054
>>>
>>> Signed-off-by: Jason Gerecke 
>>
>> Acked-by: Ping Cheng  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.

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.

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 2/2] HID: wacom: Add module description

2012-03-29 Thread Przemo Firszt

Dnia 29 Marca 2012, 3:46 pm, Cz, Jiri Kosina napisał(a):
> On Wed, 28 Mar 2012, Przemo Firszt wrote:
>
>> Add description for hid-wacom module: "Driver for Wacom Graphire
>> Bluetooth
>> and Wacom Intuos4 WL"
>>
>> Signed-off-by: Przemo Firszt 
>> ---
>>  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 f130f40..fb0fe16 100644
>> --- a/drivers/hid/hid-wacom.c
>> +++ b/drivers/hid/hid-wacom.c
>> @@ -687,5 +687,5 @@ static void __exit wacom_exit(void)
>>
>>  module_init(wacom_init);
>>  module_exit(wacom_exit);
>> +MODULE_DESCRIPTION("Driver for Wacom Graphire Bluetooth and Wacom
>> Intuos4 WL");
>
> I am a little bit unsure about having the information about supported
> models duplicate in Kconfig and MODULE_DESCRIPTION() ... it's just adding
> more places that we will forget to update once support for a new device
> line is added.
>
> Applied, but not fully convinced.
>
Hi Jiri,
Thanks! I'll come back to this issue later - I have to test an idea..
-- 
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 1/1] Use kernel-reported tilt range and resolution

2012-03-29 Thread Nikolai Kondrashov
Hi Chris,

On Thu, Mar 29, 2012 at 4:49 PM, Chris Bagwell  wrote:
> 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.

I agree. I was actually wondering if I should make it a TODO instead, but
didn't - should've thought better.

I'll fix it, will try to find someone to test it and then resubmit.

Thanks!

Sincerely,
Nick

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

2012-03-29 Thread Chris Bagwell
On Wed, Mar 28, 2012 at 12:31 PM, Ping Cheng  wrote:
> On Wed, Mar 28, 2012 at 9:29 AM, Jason Gerecke  wrote:
>> Based on upstream commit 803296b678a43005e3bc0aaa1951d211bd76a054
>>
>> Signed-off-by: Jason Gerecke 
>
> Acked-by: Ping Cheng  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 1/1] Use kernel-reported tilt range and resolution

2012-03-29 Thread Chris Bagwell
On Thu, Mar 29, 2012 at 2:22 AM, Nikolai Kondrashov  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 Kondrashov
>>> 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 1/1] Use kernel-reported tilt range and resolution

2012-03-29 Thread Nikolai Kondrashov
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 Kondrashov 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?

Thanks.

Sincerely,
Nick

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