Simple tablets

[Favux ...]

Fedora 16 and Ubuntu Oneiric no longer support the WizardPen driver so
these tablets are on the evdev driver.  The Aiptek driver is still
available though.  The problem we are running into is that pressure
doesn't seem to work on the evdev driver.

1) How do we enable pressure for "simple" tablets on the evdev driver?

They have either 512 or 1024 pressure levels.  The WizardPen driver
supported linear pressure for them.  From remarks Peter has made I
gather the simple tablets are suppose to be on the evdev (2.6) driver
for current releases.  While the evdev manual tells us how to supply X
and Y coordinates, which some of the tablets need, it is silent on the
Z-axis.  In other words are there Z axis coordinate options we should
be using and what are they?

The old 70-wizardpen.conf was of the general form:
Section "InputClass"
    Identifier "WizardPen class"
    MatchIsTablet "on"
    MatchVendor "UC-LOGIC|KYE Systems|Ace Cad"
    MatchDevicePath "/dev/input/event*"
    Driver "wizardpen"
EndSection
The MatchVendor match doesn't always work for the tablets and for
those a MatchProduct keyword match is needed.

We've been trying a /etc/X11/xorg.conf.d/52-wizardpen-on-evdev.conf snippet:
Section "InputClass"
    Identifier "WizardPen-on-evdev class"
    MatchIsTablet "on"
    MatchVendor "UC-LOGIC|KYE Systems|Ace Cad"
    MatchDevicePath "/dev/input/event*"
    Driver "evdev"
    Option "TopZ" "10"
    Option "BottomZ" "1023"
EndSection
Without success except for 1 user who seemed to be reporting success.
So I don't know if it a model specific or a general problem.

2) Does the evdev driver support a tablet mouse in addition to the
stylus for these "simple" tablets?

The WizardPen driver never supported the tablet mouse some of these
tablets have.  In fact it made the stylus non-functional so a snippet
was needed to block the mouse from the driver:
Section "InputClass"
    Identifier "WizardPen ignore mouse dev class"
    MatchIsTablet "on"
    MatchVendor "UC-LOGIC|KYE Systems|Ace Cad"
    MatchDevicePath "/dev/input/mouse*"
    Option "Ignore" "yes"
EndSection
As an aside to Peter:  the original version of this snippet was the
origin of the famous Driver "" alternate to Option "Ignore".

Thinking the evdev driver might support the mouse we've tried:
Section "InputClass"
    Identifier "WizardPen-on-evdev mouse class"
    MatchIsTablet "on"
    MatchVendor "UC-LOGIC|KYE Systems|Ace Cad"
    MatchDevicePath "/dev/input/mouse*"
    Driver "evdev"
EndSection
But we see "could not open the device /dev/input/mouse1 invalid
ioctl".  Making me wonder if the problem is due to the kernel driver
for these tablets?


Any suggestions would be appreciated.

Favux

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

[Nikolai Kondrashov-2]

On 12/28/2011 10:03 PM, Favux ... wrote:
> Fedora 16 and Ubuntu Oneiric no longer support the WizardPen driver so
> these tablets are on the evdev driver.  The Aiptek driver is still
> available though.  The problem we are running into is that pressure
> doesn't seem to work on the evdev driver.
>
> 1) How do we enable pressure for "simple" tablets on the evdev driver?

It should just work for the models supported by the kernel.

See compatibility table [1]. The latest git of the patchset has untested
support for one more model, see latest compatibility table [2]. If you need
other models supported, I would be happy to add support for them to the
kernel, provided there is anyone having the device and willing to help with
diagnostics and testing.

There should be no configuration needed, unless you have the WizardPen
driver installed and configured. In the latter case you may need to remove
WizardPen configuration. The tablets having a mouse will have it as a
separate kernel evdev device and it will be handled by the X.org evdev
driver.

Could you please specify the kernel and evdev versions? I could test them
and try to find out what went wrong.

Thanks :)

Sincerely,
Nick

[1]
http://digimend.git.sourceforge.net/git/gitweb.cgi?p=digimend/kernel-patches.git;a=blob_plain;f=COMPATIBILITY;hb=v0.4
[2]
http://digimend.git.sourceforge.net/git/gitweb.cgi?p=digimend/kernel-patches.git;a=blob_plain;f=COMPATIBILITY

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

[Favux ...]

Thank you for responding Nick.

Ubuntu Oneiric
X.Org X SErver 1.10/4  2011-08-19
kernel 3.0.0
evdev 2.6.0

There are several models reporting no pressure.  One model that has
two users reporting no pressure is the following.
lsusb:
Bus 002 Device 003: ID 0458:5011 KYE Systems Corp. (Mouse Systems)
xinput list:
⎜   ↳ Genius MousePen i608X                     id=9    [slave  pointer  (2)]

Alright I don't see a compatibility match for that.  Likely the
problem then for that tablet.  The user I don't have the lsusb for did
claim a match to:
5543:0005   UC-Logic Tablet WP8060U     Genius MousePen 8x6 Genius
MousePen i608 DigiPro WP8060**   Manhattan 8"x6"**  Iball Pen Tablet
8060U**
I've asked her for her lsusb to verify that.  I have an evtest from
her on the stylus event that just shows X and Y coordinates but no Z.
Do you need it at this point?

Interestingly another model with no pressure is also a Kye Systems.  I
have output for one of the two that have reported.
lsusb:
Bus 001 Device 004: ID 0458:5010 KYE Systems Corp. (Mouse Systems)
xinput list:
⎜   ↳ Genius EasyPen i405X                      id=11   [slave  pointer  (2)]
Again with no Vendor or Product ID match in the compatibility table.

Favux

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

[Peter Hutterer-3]

On 29/12/11 06:03 , Favux ... wrote:

> Fedora 16 and Ubuntu Oneiric no longer support the WizardPen driver so
> these tablets are on the evdev driver.  The Aiptek driver is still
> available though.  The problem we are running into is that pressure
> doesn't seem to work on the evdev driver.
>
> 1) How do we enable pressure for "simple" tablets on the evdev driver?
>
> They have either 512 or 1024 pressure levels.  The WizardPen driver
> supported linear pressure for them.  From remarks Peter has made I
> gather the simple tablets are suppose to be on the evdev (2.6) driver
> for current releases.  While the evdev manual tells us how to supply X
> and Y coordinates, which some of the tablets need, it is silent on the
> Z-axis.  In other words are there Z axis coordinate options we should
> be using and what are they?

evdev doesn't really treat any axes as a special one, it just forwards
them. pressure is supposed to come from ABS_PRESSURE from the kernel and
should just be forwarded as-is. Might be worth just running evtest
against it to get the details. ABS_Z is for d devices that have a true
z-axis.

there are no options specific to other axes than x and y though.

> 2) Does the evdev driver support a tablet mouse in addition to the
> stylus for these "simple" tablets?
>
> The WizardPen driver never supported the tablet mouse some of these
> tablets have.  In fact it made the stylus non-functional so a snippet
> was needed to block the mouse from the driver:
> Section "InputClass"
>      Identifier "WizardPen ignore mouse dev class"
>      MatchIsTablet "on"
>      MatchVendor "UC-LOGIC|KYE Systems|Ace Cad"
>      MatchDevicePath "/dev/input/mouse*"
>      Option "Ignore" "yes"
> EndSection
> As an aside to Peter:  the original version of this snippet was the
> origin of the famous Driver "" alternate to Option "Ignore".

just as a comment there: I don't really understand why the ignore is
needed here unless you have something generically matching on the
device's /dev/input/mouse device - that part should be fixed to provide
closer matching (not that it seems to matter now, just for the future -
option ignore is a last resort if a default configuration cannot work
for one specific device)

> Thinking the evdev driver might support the mouse we've tried:
> Section "InputClass"
>      Identifier "WizardPen-on-evdev mouse class"
>      MatchIsTablet "on"
>      MatchVendor "UC-LOGIC|KYE Systems|Ace Cad"
>      MatchDevicePath "/dev/input/mouse*"
>      Driver "evdev"
> EndSection
> But we see "could not open the device /dev/input/mouse1 invalid
> ioctl".  Making me wonder if the problem is due to the kernel driver
> for these tablets?

the /dev/input/mouse devices are a bit different to the /dev/input/event
devices. they speak ps2 protocol, not the event protocol and the evdev
driver doesn't understand them at all. if the wizardpen has a mouse
device like the wacom tablets have, that is either a separate kernel
device (thus another eventX device) or multiplexed on the same device
(through BTN_TOOL_*). How are the mouse devices supported?

Cheers,
   Peter

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

[Favux ...]

On Wed, Dec 28, 2011 at 5:41 PM, Peter Hutterer
<peter.hutterer@...> wrote:

> On 29/12/11 06:03 , Favux ... wrote:
>>
>> Fedora 16 and Ubuntu Oneiric no longer support the WizardPen driver so
>> these tablets are on the evdev driver.  The Aiptek driver is still
>> available though.  The problem we are running into is that pressure
>> doesn't seem to work on the evdev driver.
>>
>> 1) How do we enable pressure for "simple" tablets on the evdev driver?
>>
>> They have either 512 or 1024 pressure levels.  The WizardPen driver
>> supported linear pressure for them.  From remarks Peter has made I
>> gather the simple tablets are suppose to be on the evdev (2.6) driver
>> for current releases.  While the evdev manual tells us how to supply X
>> and Y coordinates, which some of the tablets need, it is silent on the
>> Z-axis.  In other words are there Z axis coordinate options we should
>> be using and what are they?
>
>
> evdev doesn't really treat any axes as a special one, it just forwards them.
> pressure is supposed to come from ABS_PRESSURE from the kernel and should
> just be forwarded as-is. Might be worth just running evtest against it to
> get the details. ABS_Z is for d devices that have a true z-axis.
>
> there are no options specific to other axes than x and y though.

That answers that question then.  It is a kernel problem.  And evtest
shows nothing for Z other than saying it is there:
    Event code 24 (Pressure)
      Value      0
      Min        0
      Max     1023

>> 2) Does the evdev driver support a tablet mouse in addition to the
>> stylus for these "simple" tablets?
>>
>> The WizardPen driver never supported the tablet mouse some of these
>> tablets have.  In fact it made the stylus non-functional so a snippet
>> was needed to block the mouse from the driver:
>> Section "InputClass"
>>     Identifier "WizardPen ignore mouse dev class"
>>     MatchIsTablet "on"
>>     MatchVendor "UC-LOGIC|KYE Systems|Ace Cad"
>>     MatchDevicePath "/dev/input/mouse*"
>>     Option "Ignore" "yes"
>> EndSection
>> As an aside to Peter:  the original version of this snippet was the
>> origin of the famous Driver "" alternate to Option "Ignore".
>
>
> just as a comment there: I don't really understand why the ignore is needed
> here unless you have something generically matching on the device's
> /dev/input/mouse device - that part should be fixed to provide closer
> matching (not that it seems to matter now, just for the future - option
> ignore is a last resort if a default configuration cannot work for one
> specific device)

OK, for future reference.  But I don't see how to do a more specific
match if it is multiplexed.  I guess I need to go back and review
Xorg.0.logs where the mouse is blocked.

>> Thinking the evdev driver might support the mouse we've tried:
>> Section "InputClass"
>>     Identifier "WizardPen-on-evdev mouse class"
>>     MatchIsTablet "on"
>>     MatchVendor "UC-LOGIC|KYE Systems|Ace Cad"
>>     MatchDevicePath "/dev/input/mouse*"
>>     Driver "evdev"
>> EndSection
>> But we see "could not open the device /dev/input/mouse1 invalid
>> ioctl".  Making me wonder if the problem is due to the kernel driver
>> for these tablets?
>
>
> the /dev/input/mouse devices are a bit different to the /dev/input/event
> devices. they speak ps2 protocol, not the event protocol and the evdev
> driver doesn't understand them at all. if the wizardpen has a mouse device
> like the wacom tablets have, that is either a separate kernel device (thus
> another eventX device) or multiplexed on the same device (through
> BTN_TOOL_*). How are the mouse devices supported?

While some tablets do have two events listed in 'xinput list', one of
which we were thinking might be the mouse, generally there is only one
event.  So multiplexed?  That's a question I'm hoping Nick can answer.

Favux

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

[Favux ...]

FYI Update

Viktoria.s has sent in the information Nick requested on the KYE
Systems i608X.  So far I don't think anyone has done that for the
i405X.


@ Peter

On Wed, Dec 28, 2011 at 6:15 PM, Favux ... <favux.is@...> wrote:

> On Wed, Dec 28, 2011 at 5:41 PM, Peter Hutterer
> <peter.hutterer@...> wrote:
>> On 29/12/11 06:03 , Favux ... wrote:
>>
>> 1) How do we enable pressure for "simple" tablets on the evdev driver?
>>
>> They have either 512 or 1024 pressure levels.  The WizardPen driver
>> supported linear pressure for them.  From remarks Peter has made I
>> gather the simple tablets are suppose to be on the evdev (2.6) driver
>> for current releases.  While the evdev manual tells us how to supply X
>> and Y coordinates, which some of the tablets need, it is silent on the
>> Z-axis.  In other words are there Z axis coordinate options we should
>> be using and what are they?
>
>
> evdev doesn't really treat any axes as a special one, it just forwards them.
> pressure is supposed to come from ABS_PRESSURE from the kernel and should
> just be forwarded as-is. Might be worth just running evtest against it to
> get the details. ABS_Z is for d devices that have a true z-axis.
>
> there are no options specific to other axes than x and y though.

So what then are the users to do to set Pressure Threshold?  This is
needed as I have seen values from the default of 0 ranging to 50 or
even 100 (i.e. ~ 10% of the range) before.  I don't know if this is
due to a hardware variability or the stylus battery (fresh v.s.
depleted).  Or both?

If I look at one of the tablets that work on evdev currently with:
xinput list-props 'UC-LOGIC Tablet WP5540U'

I see:
Axis Labels (247): "Abs X" (257), "Abs Y" (258), "Abs Pressure" (259)

But is "Abs Pressure" a property we can set, say using?
input --set-prop "UC-LOGIC Tablet WP5540U" --type=float "Abs Pressure" 50, 1023

Favux

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

[Peter Hutterer-3]

On Wed, Dec 28, 2011 at 06:15:11PM -0600, Favux ... wrote:

> On Wed, Dec 28, 2011 at 5:41 PM, Peter Hutterer
> <peter.hutterer@...> wrote:
> > On 29/12/11 06:03 , Favux ... wrote:
> >>
> >> Fedora 16 and Ubuntu Oneiric no longer support the WizardPen driver so
> >> these tablets are on the evdev driver.  The Aiptek driver is still
> >> available though.  The problem we are running into is that pressure
> >> doesn't seem to work on the evdev driver.
> >>
> >> 1) How do we enable pressure for "simple" tablets on the evdev driver?
> >>
> >> They have either 512 or 1024 pressure levels.  The WizardPen driver
> >> supported linear pressure for them.  From remarks Peter has made I
> >> gather the simple tablets are suppose to be on the evdev (2.6) driver
> >> for current releases.  While the evdev manual tells us how to supply X
> >> and Y coordinates, which some of the tablets need, it is silent on the
> >> Z-axis.  In other words are there Z axis coordinate options we should
> >> be using and what are they?
> >
> >
> > evdev doesn't really treat any axes as a special one, it just forwards them.
> > pressure is supposed to come from ABS_PRESSURE from the kernel and should
> > just be forwarded as-is. Might be worth just running evtest against it to
> > get the details. ABS_Z is for d devices that have a true z-axis.
> >
> > there are no options specific to other axes than x and y though.
>
> That answers that question then.  It is a kernel problem.  And evtest
> shows nothing for Z other than saying it is there:
>     Event code 24 (Pressure)
>       Value      0
>       Min        0
>       Max     1023
>
> >> 2) Does the evdev driver support a tablet mouse in addition to the
> >> stylus for these "simple" tablets?
> >>
> >> The WizardPen driver never supported the tablet mouse some of these
> >> tablets have.  In fact it made the stylus non-functional so a snippet
> >> was needed to block the mouse from the driver:
> >> Section "InputClass"
> >>     Identifier "WizardPen ignore mouse dev class"
> >>     MatchIsTablet "on"
> >>     MatchVendor "UC-LOGIC|KYE Systems|Ace Cad"
> >>     MatchDevicePath "/dev/input/mouse*"
> >>     Option "Ignore" "yes"
> >> EndSection
> >> As an aside to Peter:  the original version of this snippet was the
> >> origin of the famous Driver "" alternate to Option "Ignore".
> >
> >
> > just as a comment there: I don't really understand why the ignore is needed
> > here unless you have something generically matching on the device's
> > /dev/input/mouse device - that part should be fixed to provide closer
> > matching (not that it seems to matter now, just for the future - option
> > ignore is a last resort if a default configuration cannot work for one
> > specific device)
>
> OK, for future reference.  But I don't see how to do a more specific
> match if it is multiplexed.  I guess I need to go back and review
> Xorg.0.logs where the mouse is blocked.

none of the default config files we ship with the drivers should assign a
driver to any /dev/input/mouse device (on Linux, anyway), so any such
device should claim "No input driver/identifier specified".
If it is claimed by a driver, that means that either we ship the wrong files
your distribution added some that may be broken or you have some local
configuration that's too excessive.

> >> Thinking the evdev driver might support the mouse we've tried:
> >> Section "InputClass"
> >>     Identifier "WizardPen-on-evdev mouse class"
> >>     MatchIsTablet "on"
> >>     MatchVendor "UC-LOGIC|KYE Systems|Ace Cad"
> >>     MatchDevicePath "/dev/input/mouse*"
> >>     Driver "evdev"
> >> EndSection
> >> But we see "could not open the device /dev/input/mouse1 invalid
> >> ioctl".  Making me wonder if the problem is due to the kernel driver
> >> for these tablets?
> >
> >
> > the /dev/input/mouse devices are a bit different to the /dev/input/event
> > devices. they speak ps2 protocol, not the event protocol and the evdev
> > driver doesn't understand them at all. if the wizardpen has a mouse device
> > like the wacom tablets have, that is either a separate kernel device (thus
> > another eventX device) or multiplexed on the same device (through
> > BTN_TOOL_*). How are the mouse devices supported?
>
> While some tablets do have two events listed in 'xinput list', one of
> which we were thinking might be the mouse, generally there is only one
> event.  So multiplexed?  That's a question I'm hoping Nick can answer.

If you look at the evtest output, the BTN_TOOL_PEN, BTN_TOOL_MOUSE, etc. are
the delimiters for multiplexing. The order for stylus down, up and then
mouse down/up would be roughly:

BTN_TOOL_PEN 1
BTN_TOUCH 1
ABS_X 123
ABS_Y 456
EV_SYN

BTN_TOOL_PEN 0
BTN_TOUCH 0
EV_SYN

BTN_TOOL_MOUSE 1
BTN_TOUCH 1
ABS_X 472
ABS_Y 282
EV_SYN

BTN_TOOL_MOUSE 0
BTN_TOUCH 0
EV_SYN

If you can see a sequence like this, then the kernel properly multiplexes
it.
 
Cheers,
  Peter

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

[Peter Hutterer-3]

On Mon, Jan 02, 2012 at 03:58:27PM -0600, Favux ... wrote:

> FYI Update
>
> Viktoria.s has sent in the information Nick requested on the KYE
> Systems i608X.  So far I don't think anyone has done that for the
> i405X.
>
>
> @ Peter
>
> On Wed, Dec 28, 2011 at 6:15 PM, Favux ... <favux.is@...> wrote:
> > On Wed, Dec 28, 2011 at 5:41 PM, Peter Hutterer
> > <peter.hutterer@...> wrote:
> >> On 29/12/11 06:03 , Favux ... wrote:
> >>
> >> 1) How do we enable pressure for "simple" tablets on the evdev driver?
> >>
> >> They have either 512 or 1024 pressure levels.  The WizardPen driver
> >> supported linear pressure for them.  From remarks Peter has made I
> >> gather the simple tablets are suppose to be on the evdev (2.6) driver
> >> for current releases.  While the evdev manual tells us how to supply X
> >> and Y coordinates, which some of the tablets need, it is silent on the
> >> Z-axis.  In other words are there Z axis coordinate options we should
> >> be using and what are they?
> >
> >
> > evdev doesn't really treat any axes as a special one, it just forwards them.
> > pressure is supposed to come from ABS_PRESSURE from the kernel and should
> > just be forwarded as-is. Might be worth just running evtest against it to
> > get the details. ABS_Z is for d devices that have a true z-axis.
> >
> > there are no options specific to other axes than x and y though.
>
> So what then are the users to do to set Pressure Threshold?  This is
> needed as I have seen values from the default of 0 ranging to 50 or
> even 100 (i.e. ~ 10% of the range) before.  I don't know if this is
> due to a hardware variability or the stylus battery (fresh v.s.
> depleted).  Or both?
>
> If I look at one of the tablets that work on evdev currently with:
> xinput list-props 'UC-LOGIC Tablet WP5540U'
>
> I see:
> Axis Labels (247): "Abs X" (257), "Abs Y" (258), "Abs Pressure" (259)
>
> But is "Abs Pressure" a property we can set, say using?
> input --set-prop "UC-LOGIC Tablet WP5540U" --type=float "Abs Pressure" 50, 1023

Abs Pressure is just a label to help clients. In XI 1.x devices can have
multiple axes but a client cannot know which one is pressure, which one is
tilt, etc. That's why GTK provides that input device dialog.

In evdev 2.2, we added axis labels. So the above property says "three axes,
first one is an absolute x axes, second one is an absolute y axis, third one
is an absolute pressure axis". it's read-only since the device won't really
change it's physical properties by changing a few bits ;)
In XI2, axis labels are built into the protocol and this property is
not necessary anymore.

As with all properties, they require driver support if they should change
anything. Right now the evdev driver has no support for a pressure threshold
feature. The above command you posted would simply create a new property
called "Abs Pressure", type float, with two values. Nothing in the driver
reads that property though, so it has little effect on the device.

Cheers,
  Peter

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

[Nikolai Kondrashov-2]

Hi Favux,

Sorry for the delay with the answer.

On 12/29/2011 02:15 AM, Favux ... wrote:
> While some tablets do have two events listed in 'xinput list', one of
> which we were thinking might be the mouse, generally there is only one
> event.  So multiplexed?  That's a question I'm hoping Nick can answer.

I'll try to answer all of your questions here. Sorry if I went too far and
tried to explain too much, but at the time it seemed necessary.

Note: by cheap graphics tablets I mean simple tablets originally produced by
UC-Logic, Waltop and KYE Systems (Genius). The UC-Logic and Waltop tablets
are sold under multitude of names, while KYE Systems sells its tablets only
under its "Genius" name, it seems.

First, a quick overview of the whole stack (please don't trust me too much
on the details - better check the code).

USB devices can have several interfaces, each interface has a class and
there is a HID (human interface device) class which is used by various input
devices. All the cheap graphics tablets I've seen only had one, HID-class
interface. Every HID interface must have a report descriptor, describing
meaning (usages) and value ranges of bits in one or more
input/output/feature reports. We're only concerned with the input reports
here.

In the kernel, USB tablets without specific drivers are handled by the
generic HID driver (usbhid). It creates an evdev device for every HID
interface by default. It reads the HID report descriptor from the tablet and
builds a mapping between the usages of input report bits and evdev event
types and codes. So that, say, in a 7 byte report, first three words are
reported as ABS_X/Y/PRESSURE, and a bitmask in the last byte is reported as
BTN_TOUCH/STYLUS/STYLUS2.

X.org is usually configured so that evdev input devices without specific
drivers are handled by the generic xf86-input-evdev driver. It checks which
event types and codes the device reports and tries to guess the device type
(mouse, tablet, keyboard, touchpad, maybe something else). For example, a
device with REL_X/Y and BTN_LEFT/RIGHT is very probably a mouse, lots of
KEY_* codes signify a keyboard, and then a device with ABS_X/Y/PRESSURE is
quite likely a tablet or a touchpad. It then proceeds to creating an X input
device and translating the evdev events into X input events correspondingly.

Wacom USB tablets are handled by a special kernel driver (wacom), which uses
complex sequences of evdev events to report the input. The only X driver
capable of handling that input fully is xf86-input-wacom. Among other
things, the kernel driver uses BTN_TOOL_* codes to report which tool is
entering/leaving the proximity of the digitizer, and ABS_X/Y/PRESSURE/etc
codes to report the tool location and state.

Peter, please correct me if you've noticed anything wrong. Thanks :)

Now about the cheap tablets.

These tablets almost never have completely correct USB HID report
descriptors. They often describe seemingly unused reports, which sometimes
have input usages overlapping with actually used reports. Then, they may
simply have incorrect usages describing the report bits.

This doesn't make much sense to the usbhid kernel driver. If it sees a usage
in a report description, which was already claimed by a previous report
description, it will map it into next available event code. For example,
UC-Logic WP8060U has its first (unused) pen report assigned to ABS_X and
ABS_Y, while the next (actually used) pen report gets assigned ABS_Z and
ABS_RX for pen coordinates.

If such tablets have any controls except pen, like mouse, rotary controls
and/or buttons on the frame, they put them into a single interface (i.e.
report descriptor) using separate report descriptions (report IDs). This
results in usbhid driver reporting them in a single evdev device.

This makes even less sense to xf86-input-evdev. From its point of view
these tablets may report both relative and absolute coordinates (when they
have a mouse), some multimedia keys (when they have some buttons or dials on
the frame), or even just bogus axes and buttons. Then, the best half of
these inputs, which actually makes sense, may be dead.

Now, the wizardpen driver steps in. It basically translates gibberish evdev
events into meaningful X input events. This seems to me ineffective, because
the driver doesn't really do much (a simple translation layer for evdev
might be enough), only serves X (console, Wayland and other possible
applications are left in the cold).

That's why, after helping develop the wizardpen driver for a while, I
switched to working on the kernel and evdev. Basically, what I do in the
kernel so far, is feeding the usbhid driver corrected report descriptors and
asking it to create a separate evdev device for every report description
(report ID). Thus the evdev devices report correct event types and codes and
"multitool" tablets get a separate device for every "tool" (i.e.  pen,
mouse, controls on the frame). The wacom-style multiplexing is not easily
possible with these tablets, because they mostly don't report tool proximity
events.

It is said that some Waltop tablets work with the xf86-input-wacom driver,
yet I'm not sure how they manage that. The xf86-input-wacom expects quite a
lot from the evdev device. Maybe it's because they're the only cheap tablets
which have pen proximity events. I've tried to approach xf86-input-wacom
code several times in order to add support for the cheap tablets, and
although it worked with a few hacks, it required quite a lot of changes to
be done properly and I didn't have enough time and energy to do that so far.

Still, some of the cheap tablets don't have full functionality enabled by
default, probably for compatibility with generic Windows/MacOS HID drivers,
and need to have it enabled explicitly. Otherwise, they may have lower
resolution, low control over buttons on the frame, or no pressure data at
all. They don't use standard means to enable this mode, like switching
device configurations. Instead, they may require sending specially crafted
feature reports. This is the case with Waltop tablets, although they still
remain useful, except for higher-end models which may have crippled
resolution and/or button control.

This is also the case with Genius EasyPen i405X and i608X, it seems. They
only report pen position and button state, but not pressure. Yet, even that
is not usable by xf86-input-evdev with the usbhid kernel driver because of
their messed up report descriptors.

It is unknown to me how to enable fully functional mode for these tablets.
We could either ask KYE Systems (Genius) or sniff the Windows driver USB
traffic. I have already asked Viktoria to do the latter, but I'm not sure
if she will be able to do that and when. Maybe some of your other users will
be able to do that.

It would really speed it up if I had access to one of these tablets.
Unfortunately, they don't seem to be sold in Finland, where I currently
live. So, I can't go into a shop and ask for diagnostics to be taken as I
did with other tablets. I also don't have much money available to buy them
from online shops, especially since I don't have further use for them.

I hope this answers your questions. Yet, feel free to ask more :)

Sincerely,
Nick

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

[Nikolai Kondrashov-2]

On Tue, Jan 3, 2012 at 12:20 PM, Nikolai Kondrashov <spbnick@...> wrote:
> I hope this answers your questions. Yet, feel free to ask more :)

Here are some links to complement the text:

USB HID specification:
http://www.usb.org/developers/devclass_docs/HID1_11.pdf

Evdev event codes documentation:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/input/event-codes.txt

Waltop and UC-Logic tablet kernel "drivers" done by me, explaining what's
wrong with them:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/hid/hid-waltop.c
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/hid/hid-uclogic.c

Information on various tablets I've gathered, along with fixed report
descriptors:
http://digimend.git.sourceforge.net/git/gitweb.cgi?p=digimend/devices.git;a=tree

Sincerely,
Nick

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

[Chris Bagwell]

On Tue, Jan 3, 2012 at 4:20 AM, Nikolai Kondrashov <spbnick@...> wrote:
> Hi Favux,
>

Nice write up.  I wish there was a good web page to store the info at.

I wanted to throw in 1 reply.

> That's why, after helping develop the wizardpen driver for a while, I
> switched to working on the kernel and evdev. Basically, what I do in the
> kernel so far, is feeding the usbhid driver corrected report descriptors and
> asking it to create a separate evdev device for every report description
> (report ID). Thus the evdev devices report correct event types and codes and
> "multitool" tablets get a separate device for every "tool" (i.e.  pen,
> mouse, controls on the frame). The wacom-style multiplexing is not easily
> possible with these tablets, because they mostly don't report tool proximity
> events.
>
> It is said that some Waltop tablets work with the xf86-input-wacom driver,
> yet I'm not sure how they manage that. The xf86-input-wacom expects quite a
> lot from the evdev device. Maybe it's because they're the only cheap tablets
> which have pen proximity events. I've tried to approach xf86-input-wacom
> code several times in order to add support for the cheap tablets, and
> although it worked with a few hacks, it required quite a lot of changes to
> be done properly and I didn't have enough time and energy to do that so far.
>

xf86-input-wacom may be in better shape since you last approached it
(or not :) ).  I've added some logic to work with wider range of
devices.  For example, I use it with a cheap touchscreen that has no
stylus support (hid-multitouch driver) quite a bit.

There is 1 issue left in and its cause is related to what you say
above from Linux HID point of view.

The key is that xf86-input-wacom requires evdev to declare at least 1
BTN_TOOL_* and it uses this information to auto-hotplug devices for
each tool to then un-multiplex the data to.  Technically, we could
assume its a PEN device if no BTN_TOOL_* is declared but that felt
unsafe at the time (xf86-input-synaptics also is strict and requires a
BTN_TOOL_FINGER to be declared).

In Linux HID driver, I believe it is "In Range" that creates the
BTN_TOOL_PEN/FINGER event; so if Waltop is the only cheaper tablet
that supports that event then it explains why its only one working.
My cheap touchscreen happens to support both "In Range" and "Tip
Switch" and they just mirror each other at all times; and thats what
its working with xf86-input-wacom.

If a kernel driver was somehow able to have BTN_TOOL_PEN exactly match
"Tip Switch"/BTN_TOUCH value then I think xf86-input-wacom would be
happy to work with any simple tablet as well.

I just recently was looking over your kernel code and did like that
approach of patching up the HID report to get it working with generic
drivers.  We could also do that with a wide range of Wacom hardware as
well.  The only down side being that you can't do these small tweaks;
like force BTN_TOOL_PEN to follow BTN_TOUCH; so easy anymore.

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
_______________________________________________
Linuxwacom-discuss mailing list
Linuxwacom-discuss@...
https://lists.sourceforge.net/lists/listinfo/linuxwacom-discuss

[Favux ...]

Thank you Chris.  And thank you Peter and Nick for taking the time to
reply.  I have a much better handle on what's going on now.  I have
tried to convey a little of that to the tablet users on Ubuntu forums.
 And I have mentioned you are looking for Windows usb data to learn
how to switch the KYE System tablets on.

I want to echo Chris' mention of a good web page for this information.
 Nick if you ever decide to host MediaWiki on your DIGImend
sourceforge site I think you have a good start on some content to
populate it.  I have had a link to your DIGImend site on the
Waltop_Tablet_Set_Up HOWTO for quite a while now:
http://sourceforge.net/apps/mediawiki/linuxwacom/index.php?title=Waltop_Tablet_Set_Up

Favux

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

[Nikolai Kondrashov-2]

Hi Favux,

On 01/04/2012 12:31 AM, Favux ... wrote:
> Thank you Chris.  And thank you Peter and Nick for taking the time to
> reply.  I have a much better handle on what's going on now.  I have
> tried to convey a little of that to the tablet users on Ubuntu forums.
>   And I have mentioned you are looking for Windows usb data to learn
> how to switch the KYE System tablets on.

Viktoria has helped me to discover the way to make the KYE tablets report
all the data, including pressure. This was tested with EasyPen i405X,
EasyPen M610X and MousePen i608X in userspace with modified usbhid-dump.
However, so far I've failed to make it work in a kernel driver. Several
versions of the driver were tested by tablet owners with only limited
success. Thus, I just went and ordered an EasyPen i405X from Amazon UK.
I hope once it gets into my hands, the victory will be swift.

> I want to echo Chris' mention of a good web page for this information.
>   Nick if you ever decide to host MediaWiki on your DIGImend
> sourceforge site I think you have a good start on some content to
> populate it.  I have had a link to your DIGImend site on the
> Waltop_Tablet_Set_Up HOWTO for quite a while now:
> http://sourceforge.net/apps/mediawiki/linuxwacom/index.php?title=Waltop_Tablet_Set_Up

Thanks. I'm now thinking how to arrange this best. There is sure much to
tell the users. The only problem is my time and energy, as usual :)

Sincerely,
Nick

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

[Favux ...]

On Fri, Jan 27, 2012 at 3:06 PM, Nikolai Kondrashov <spbnick@...> wrote:
> Hi Favux,
>
> Viktoria has helped me to discover the way to make the KYE tablets report
> all the data, including pressure. This was tested with EasyPen i405X,
> EasyPen M610X and MousePen i608X in userspace with modified usbhid-dump.

That is great!  Congratulations to you two.

> However, so far I've failed to make it work in a kernel driver. Several
> versions of the driver were tested by tablet owners with only limited
> success. Thus, I just went and ordered an EasyPen i405X from Amazon UK.
> I hope once it gets into my hands, the victory will be swift.

I'm confident you'll get the kernel driver working.  I'll update the
Ubuntu forum threads to let them know that tablets are close to being
supported in the kernel.

>> I want to echo Chris' mention of a good web page for this information.
>>  Nick if you ever decide to host MediaWiki on your DIGImend
>> sourceforge site I think you have a good start on some content to
>> populate it.
>
> Thanks. I'm now thinking how to arrange this best. There is sure much to
> tell the users. The only problem is my time and energy, as usual :)

Of course.  If there is anything I can do to help let me know.

> Sincerely,
> Nick

Thanks,
Favux

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

[Nikolai Kondrashov-2]

Hi Favux, Chris,

On 01/28/2012 05:40 AM, Favux ... wrote:
>>> I want to echo Chris' mention of a good web page for this information.
>>>   Nick if you ever decide to host MediaWiki on your DIGImend
>>> sourceforge site I think you have a good start on some content to
>>> populate it.
>>
>> Thanks. I'm now thinking how to arrange this best. There is sure much to
>> tell the users. The only problem is my time and energy, as usual :)
>
> Of course.  If there is anything I can do to help let me know.

The draft wiki has just went live at http://digimend.sf.net. It already
covers roughly what the old page was telling, with some additions.  Notably,
the tablet support status page [1], linking to information about all the
known tablets.

I would appreciate any help. Maybe you could put something on the Wacom
driver setup HOWTO page [2]. My English isn't perfect and would benefit from
some corrections, also.

Thanks :)

Sincerely,
Nick

[1] http://sf.net/apps/mediawiki/digimend/?title=Tablet_support_status
[2] http://sf.net/apps/mediawiki/digimend/?title=Tablet_setup_with_xf86-input-wacom

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

[Favux ...]

Hi Nick,

The initial preliminary page for Tablet_setup_with_xf86-input-wacom
has been posted on your Digimend mediawiki.

My concern is I may have jumped the gun adding WALTOP back into the
50-wacom.conf if it turns out evdev is the preferred X driver for
Waltops.  Something you and Chris may want to continue discussing.

Favux

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

[Nikolai Kondrashov-2]

Hi Dave,

On 03/07/2012 08:29 PM, Favux ... wrote:
> The initial preliminary page for Tablet_setup_with_xf86-input-wacom
> has been posted on your Digimend mediawiki.

Great! Thanks a lot :)!
I'll be reading it thoroughly and maybe asking questions/correcting
some things tomorrow.

> My concern is I may have jumped the gun adding WALTOP back into the
> 50-wacom.conf if it turns out evdev is the preferred X driver for
> Waltops.  Something you and Chris may want to continue discussing.

Actually, guys from Waltop were gracious to send me two quite advanced
sample tablets recently, so I'll be able to test them properly and finally
decide on the preferred driver with Chris and your help.

I like evdev code (low) complexity and wacom's features, but not the other
way around. I will need to either read thoroughly/refactor some wacom driver
parts to be confident, or add more tablet-related features to the evdev
driver.

Sincerely,
Nick

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