Aiptek USB Tablet Driver for Linux/XFree

No, because xinput --list knows the tablet's driver is loaded.

-----Original Message-----
>From: steve <steve@...>
>Sent: Dec 5, 2009 6:05 AM
>To: aiptektablet-users@...
>Subject: Re: [Aiptektablet-users] gaiptek status?
>
>On Saturday 05 December 2009 08:40:29 Bjorn Wielens wrote:
>> Well, I have some good news- I managed to get gaiptek to compile and it
>> runs. (must have obtained an SVN checkout that was still a WIP last time).
>> 
>> Anyway, when I launch it, I get the infamous "there is no xserver driver
>> associated with the tablet" error message...
>> yet it is listed properly in xinput --list.
>> 
>> Any idea what causes this?
>
>I think it's to do with xorg not using etc/X11/xorg.conf anymore. You have to 
>configure the tablet using hal.
>Cheers Steve.
>
>------------------------------------------------------------------------------
>Join us December 9, 2009 for the Red Hat Virtual Experience,
>a free event focused on virtualization and cloud computing. 
>Attend in-depth sessions from your desk. Your couch. Anywhere.
>http://p.sf.net/sfu/redhat-sfdev2dev
>_______________________________________________
>Aiptektablet-users mailing list
>Aiptektablet-users@...
>https://lists.sourceforge.net/lists/listinfo/aiptektablet-users

This is true, and the initialization is also appearing in
/var/log/Xorg.0.log.

I'm hoping that if I/we can get gaiptek working, that it will resolve
the issues, which seem to be related to pressure behaviour.

My guess is that the HAL fdi file isn't working properly yet, since
despite specifying the tablet in absolute mode and programming it that
way, I get errors about relative reports until I reprogram it with the
sysfs interface.

While I have little kernel module experience, I am somewhat familiar
with C and will gladly help out with testing etc. where I can.

Bjorn.



Bryan W. Headley wrote:
> No, because xinput --list knows the tablet's driver is loaded.
> 
> -----Original Message-----
>> From: steve <steve@...>
>> Sent: Dec 5, 2009 6:05 AM
>> To: aiptektablet-users@...
>> Subject: Re: [Aiptektablet-users] gaiptek status?
>>
>> On Saturday 05 December 2009 08:40:29 Bjorn Wielens wrote:
>>> Well, I have some good news- I managed to get gaiptek to compile and it
>>> runs. (must have obtained an SVN checkout that was still a WIP last time).
>>>
>>> Anyway, when I launch it, I get the infamous "there is no xserver driver
>>> associated with the tablet" error message...
>>> yet it is listed properly in xinput --list.
>>>
>>> Any idea what causes this?
>> I think it's to do with xorg not using etc/X11/xorg.conf anymore. You have to 
>> configure the tablet using hal.
>> Cheers Steve.
>>
>> ------------------------------------------------------------------------------
>> Join us December 9, 2009 for the Red Hat Virtual Experience,
>> a free event focused on virtualization and cloud computing. 
>> Attend in-depth sessions from your desk. Your couch. Anywhere.
>> http://p.sf.net/sfu/redhat-sfdev2dev
>> _______________________________________________
>> Aiptektablet-users mailing list
>> Aiptektablet-users@...
>> https://lists.sourceforge.net/lists/listinfo/aiptektablet-users
> 
> 
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing. 
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Aiptektablet-users mailing list
> Aiptektablet-users@...
> https://lists.sourceforge.net/lists/listinfo/aiptektablet-users
>

Bjorn Wielens wrote:
> This is true, and the initialization is also appearing in
> /var/log/Xorg.0.log.
>
> I'm hoping that if I/we can get gaiptek working, that it will resolve
> the issues, which seem to be related to pressure behaviour.
>
> My guess is that the HAL fdi file isn't working properly yet, since
> despite specifying the tablet in absolute mode and programming it that
> way, I get errors about relative reports until I reprogram it with the
> sysfs interface.
>
> While I have little kernel module experience, I am somewhat familiar
> with C and will gladly help out with testing etc. where I can.
>   
-=-=
If "xinput --list" is aware of the aiptek driver, then obviously its 
loaded. The xorg driver should be capable of to replying "AIPTEK" if 
sent "DRIVER" (unless someone took it out -- and, yes, they DID TAKE 
THAT OUT!!!)

Well, that makes me very unhappy. My email address is all over that 
code, someone could easily contact me and ask what the routine is there 
for. And there is a lot of comments in the kernel code, the xorg code, 
and gaiptek, and they EVEN CROSS REFERENCE EACH OTHER. But they can't 
read comments nor can they send me email (at least I never got any) 
asking how it works, so they took that out & released it.

I'm rather furious right now. Where I might try to reorient myself with 
what's been done, my tablet's in a closet somewhere.

Make THEM support it.

Heh... I'd be pretty cheesed off too...

Time to give 'em hell- nothing is more dangerous than meddling in
something with only a little knowledge.

Bjorn.


On 12/07/2009 05:50 PM, Bryan Headley wrote:
> Bjorn Wielens wrote:
>> This is true, and the initialization is also appearing in
>> /var/log/Xorg.0.log.
>>
>> I'm hoping that if I/we can get gaiptek working, that it will resolve
>> the issues, which seem to be related to pressure behaviour.
>>
>> My guess is that the HAL fdi file isn't working properly yet, since
>> despite specifying the tablet in absolute mode and programming it that
>> way, I get errors about relative reports until I reprogram it with the
>> sysfs interface.
>>
>> While I have little kernel module experience, I am somewhat familiar
>> with C and will gladly help out with testing etc. where I can.
>>   
> -=-=
> If "xinput --list" is aware of the aiptek driver, then obviously its 
> loaded. The xorg driver should be capable of to replying "AIPTEK" if 
> sent "DRIVER" (unless someone took it out -- and, yes, they DID TAKE 
> THAT OUT!!!)
> 
> Well, that makes me very unhappy. My email address is all over that 
> code, someone could easily contact me and ask what the routine is there 
> for. And there is a lot of comments in the kernel code, the xorg code, 
> and gaiptek, and they EVEN CROSS REFERENCE EACH OTHER. But they can't 
> read comments nor can they send me email (at least I never got any) 
> asking how it works, so they took that out & released it.
> 
> I'm rather furious right now. Where I might try to reorient myself with 
> what's been done, my tablet's in a closet somewhere.
> 
> Make THEM support it.
> 
> 
> 
> ------------------------------------------------------------------------------
> Return on Information:
> Google Enterprise Search pays you back
> Get the facts.
> http://p.sf.net/sfu/google-dev2dev
> _______________________________________________
> Aiptektablet-users mailing list
> Aiptektablet-users@...
> https://lists.sourceforge.net/lists/listinfo/aiptektablet-users
>

Bjorn Wielens wrote:
> Heh... I'd be pretty cheesed off too...
>
> Time to give 'em hell- nothing is more dangerous than meddling in
> something with only a little knowledge.
>   
They were in charge. I retired from this project years ago. But now 
they're retired. There should be a rule about retiring: always find a 
replacement, first.

Well, I will see what wacom is doing tomorrow, and try to work out a 
strategy. I think though that I might have to write stuff for hal as 
well. Its bothersome because I thought hal was being retired for 
PackageKit and PolicyKit...

I don't know what to do about the keyboard, though. The xorg guys put an 
#ifdef around that code, so it won't compile for 7.5 and newer.

Would it be an idea that the function keys be mapped to additional
"mouse" buttons?




On 12/07/2009 11:50 PM, Bryan Headley wrote:
> Bjorn Wielens wrote:
>> Heh... I'd be pretty cheesed off too...
>>
>> Time to give 'em hell- nothing is more dangerous than meddling in
>> something with only a little knowledge.
>>   
> They were in charge. I retired from this project years ago. But now 
> they're retired. There should be a rule about retiring: always find a 
> replacement, first.
> 
> Well, I will see what wacom is doing tomorrow, and try to work out a 
> strategy. I think though that I might have to write stuff for hal as 
> well. Its bothersome because I thought hal was being retired for 
> PackageKit and PolicyKit...
> 
> I don't know what to do about the keyboard, though. The xorg guys put an 
> #ifdef around that code, so it won't compile for 7.5 and newer.
> 
> 
> 
> ------------------------------------------------------------------------------
> Return on Information:
> Google Enterprise Search pays you back
> Get the facts.
> http://p.sf.net/sfu/google-dev2dev
> _______________________________________________
> Aiptektablet-users mailing list
> Aiptektablet-users@...
> https://lists.sourceforge.net/lists/listinfo/aiptektablet-users
>

Bjorn Wielens wrote:
> Would it be an idea that the function keys be mapped to additional
> "mouse" buttons?
>   
Its possible, but, the driver wouldn't know you "stopped" pressing the 
mouse button, unless I did something like force you to press the macro 
key area once to press the button, then again to release the button. If 
there were little lights over the macro keys, it might work (it lights 
up when the "button: is pressed.) But at that stage, I'd ask if it'd be 
easier for Gaiptek to send the fake button event.

The thing to do (perhaps) is load the evdev driver and tell it to parse 
keyboard events from the tablet. I don't yet know. Having several 
drivers "read" from the same physical device is stupid, too. But we 
already do that :-)

Ah.... that would be troublesome. I take it then that the tablet does
not report pressure events when you touch the stylus on the macro areas?

This is quite a can of worms I seem to have opened up!


On 12/08/2009 01:21 PM, Bryan Headley wrote:
> Bjorn Wielens wrote:
>> Would it be an idea that the function keys be mapped to additional
>> "mouse" buttons?
>>   
> Its possible, but, the driver wouldn't know you "stopped" pressing the 
> mouse button, unless I did something like force you to press the macro 
> key area once to press the button, then again to release the button. If 
> there were little lights over the macro keys, it might work (it lights 
> up when the "button: is pressed.) But at that stage, I'd ask if it'd be 
> easier for Gaiptek to send the fake button event.
> 
> The thing to do (perhaps) is load the evdev driver and tell it to parse 
> keyboard events from the tablet. I don't yet know. Having several 
> drivers "read" from the same physical device is stupid, too. But we 
> already do that :-)
> 
> ------------------------------------------------------------------------------
> Return on Information:
> Google Enterprise Search pays you back
> Get the facts.
> http://p.sf.net/sfu/google-dev2dev
> _______________________________________________
> Aiptektablet-users mailing list
> Aiptektablet-users@...
> https://lists.sourceforge.net/lists/listinfo/aiptektablet-users
>

Bjorn Wielens wrote:
> Ah.... that would be troublesome. I take it then that the tablet does
> not report pressure events when you touch the stylus on the macro areas?
>   
Sure it does. Don't you want to draw at the same time as the button 
being pressed? I assume you do...
If you just want to press the "mouse" button, then later draw without 
the button being pressed, accommodating you is easier.

What do you do for older xorg, which still supports the macro keys? Take 
that support away?

And I still haven't had it proved to me that keyboard support is not 
possible.

Ah... hadn't thought of that...

On 12/08/2009 01:47 PM, Bryan Headley wrote:
> Bjorn Wielens wrote:
>> Ah.... that would be troublesome. I take it then that the tablet does
>> not report pressure events when you touch the stylus on the macro areas?
>>   
> Sure it does. Don't you want to draw at the same time as the button 
> being pressed? I assume you do...
> If you just want to press the "mouse" button, then later draw without 
> the button being pressed, accommodating you is easier.
> 
> What do you do for older xorg, which still supports the macro keys? Take 
> that support away?
> 
> And I still haven't had it proved to me that keyboard support is not 
> possible.
> 
> ------------------------------------------------------------------------------
> Return on Information:
> Google Enterprise Search pays you back
> Get the facts.
> http://p.sf.net/sfu/google-dev2dev
> _______________________________________________
> Aiptektablet-users mailing list
> Aiptektablet-users@...
> https://lists.sourceforge.net/lists/listinfo/aiptektablet-users
>

Well, I managed to get the "proper" versions of the driver (from SVN) to
compile and load in to X... but now my tablet is basically a
proximity-sensing X crasher... (yes, THAT old bug again.) Also, it seems
that despite having the correct query/response routines, gaiptek still
can't find the driver.... so it looks like some of the functions have
been deprecated.

Bjorn.


On 12/08/2009 02:06 PM, Bjorn Wielens wrote:
> Ah... hadn't thought of that...
> 
> On 12/08/2009 01:47 PM, Bryan Headley wrote:
>> Bjorn Wielens wrote:
>>> Ah.... that would be troublesome. I take it then that the tablet does
>>> not report pressure events when you touch the stylus on the macro areas?
>>>   
>> Sure it does. Don't you want to draw at the same time as the button 
>> being pressed? I assume you do...
>> If you just want to press the "mouse" button, then later draw without 
>> the button being pressed, accommodating you is easier.
>>
>> What do you do for older xorg, which still supports the macro keys? Take 
>> that support away?
>>
>> And I still haven't had it proved to me that keyboard support is not 
>> possible.
>>
>> ------------------------------------------------------------------------------
>> Return on Information:
>> Google Enterprise Search pays you back
>> Get the facts.
>> http://p.sf.net/sfu/google-dev2dev
>> _______________________________________________
>> Aiptektablet-users mailing list
>> Aiptektablet-users@...
>> https://lists.sourceforge.net/lists/listinfo/aiptektablet-users
>>
> 
> 
> 
> ------------------------------------------------------------------------------
> Return on Information:
> Google Enterprise Search pays you back
> Get the facts.
> http://p.sf.net/sfu/google-dev2dev
> 
> 
> 
> _______________________________________________
> Aiptektablet-users mailing list
> Aiptektablet-users@...
> https://lists.sourceforge.net/lists/listinfo/aiptektablet-users

Bjorn Wielens wrote:
> Well, I managed to get the "proper" versions of the driver (from SVN) to
> compile and load in to X... but now my tablet is basically a
> proximity-sensing X crasher... (yes, THAT old bug again.) Also, it seems
> that despite having the correct query/response routines, gaiptek still
> can't find the driver.... so it looks like some of the functions have
> been deprecated.
>   

Whose SVN? Not aiptektablet's -- the only thing up to date in there is 
gaiptek.kde. What's that? You'd think someone merging things for the 
kernel and xorg would have kept pristine copies in our SVN repository? 
Not so.

So, you ran Gaiptek through the debugger and saw the response string get 
returned by the driver?

I'm busy trying to understand what's been done to the xorg driver and 
how much of it is (still) correct. And learning the new Xi system.

Lord, all three pieces of software are going to have to be touched. I'm 
really starting to hate how the KDE version appears and am not happy 
that there isn't a consensus between distributions on what modules 
kdevelop is delivered with. OpenSuse has the ui designer tool while 
Ubuntu's recently became stable on 9.10 (without ui). And there still 
isn't a version for kde 4. Next stop is Java with a one or two JNI/C 
routines to talk to the xServer and the Linux Input layer.

> Whose SVN? Not aiptektablet's -- the only thing up to date in there is
> gaiptek.kde. What's that? You'd think someone merging things for the
> kernel and xorg would have kept pristine copies in our SVN repository?
> Not so.

The driver from the sourceforge one- since it was the only version that
we know of that reliably contains the query/response code.

>
> So, you ran Gaiptek through the debugger and saw the response string get
> returned by the driver?

No, I haven't tried that yet- the driver did not return the response
string because I strill get the error. I meant, "despite it being
present in the code".


I agree with your rant- There needs to be some form of stanardization
across linux distros... even just lib files can be in one of three (or
more) places. Royal PITA.

Bjorn.
















>
> I'm busy trying to understand what's been done to the xorg driver and
> how much of it is (still) correct. And learning the new Xi system.
>
> Lord, all three pieces of software are going to have to be touched. I'm
> really starting to hate how the KDE version appears and am not happy
> that there isn't a consensus between distributions on what modules
> kdevelop is delivered with. OpenSuse has the ui designer tool while
> Ubuntu's recently became stable on 9.10 (without ui). And there still
> isn't a version for kde 4. Next stop is Java with a one or two JNI/C
> routines to talk to the xServer and the Linux Input layer.

On 12/08/2009 05:18 PM, Bryan Headley wrote:
> Bjorn Wielens wrote:
>> Well, I managed to get the "proper" versions of the driver (from SVN) to
>> compile and load in to X... but now my tablet is basically a
>> proximity-sensing X crasher... (yes, THAT old bug again.) Also, it seems
>> that despite having the correct query/response routines, gaiptek still
>> can't find the driver.... so it looks like some of the functions have
>> been deprecated.
>>   
> 
> Whose SVN? Not aiptektablet's -- the only thing up to date in there is 
> gaiptek.kde. What's that? You'd think someone merging things for the 
> kernel and xorg would have kept pristine copies in our SVN repository? 
> Not so.
> 
> So, you ran Gaiptek through the debugger and saw the response string get 
> returned by the driver?
> 
> I'm busy trying to understand what's been done to the xorg driver and 
> how much of it is (still) correct. And learning the new Xi system.
> 
> Lord, all three pieces of software are going to have to be touched. I'm 
> really starting to hate how the KDE version appears and am not happy 
> that there isn't a consensus between distributions on what modules 
> kdevelop is delivered with. OpenSuse has the ui designer tool while 
> Ubuntu's recently became stable on 9.10 (without ui). And there still 
> isn't a version for kde 4. Next stop is Java with a one or two JNI/C 
> routines to talk to the xServer and the Linux Input layer.
> 
> ------------------------------------------------------------------------------
> Return on Information:
> Google Enterprise Search pays you back
> Get the facts.
> http://p.sf.net/sfu/google-dev2dev
> _______________________________________________
> Aiptektablet-users mailing list
> Aiptektablet-users@...
> https://lists.sourceforge.net/lists/listinfo/aiptektablet-users
>