Alan Stern wrote:
>>> Isn't that exactly what it's supposed to do? What good is a driver if it
>>> doesn't wait for the device to send data?
>> Right, it waits, but I does not if I want it to wait...
>
> You mean, sometimes you want it to wait for data and sometimes you don't?
> I still don't understand. Is the real problem caused by the driver or is
> it caused by the device?
I'm not sure. Because I do not have any further documentation about the
device, I must solve it without it.
>>> Your question isn't clear. It looks like you're asking how to restart the
>>> transfer. The answer is obvious: Change the driver back so that it _does_
>>> call usb_submit_urb() inside atp_complete().
>> Yes will call the 'usb_submit_urb' in each invocation of the 'atp_complete'
>> function. And if I do this the 'atp_complete' function will be called
>> continuously.
>
> That isn't right. It should be called only when the device transfers some
> data, not continuously. Are you saying that the device constantly sends
> data, even when you aren't touching the pad? You should try using usbmon
> to examine the data you receive.
It constantly sent data, because the touchpad consist of temperature sensors
and the driver has to constantly save the current value to get precise
readings. I think that is the reason why the device did not stop sending
the data.
>> My problem is: If I decide (upon the data I received from the touchpad), that
>> there isn't a finger any longer on the pad, I want to stop the calling of the
>> 'atp_complete' function until I'm sure the touchpad is touched again.
>
> It sounds like you need to tell the touchpad not to send any data when it
> isn't being touched.
Lack of documentation is here the problem. Does anybody know, where I can get
the doc for Geyser (is this the name of the firm?) Touchpads? :-(
>> After I suspend and resume the computer this works. How can I archive this
>> within the interrupt-handler-code?
>
> How can you prevent the completion handler from being called? There are
> two ways: (1) Stop resubmitting the URB, or (2) Tell the device not to
> send any data.
I tried to stop resubmitting (by NOT calling "usb_submit_urb" again) and I
hoped the the interrupt handler will continue when the touchpad is pressed
again, but it does not work.
>> Another possibility (for me) would be to make the interval (in the untouched
>> times)
>> longer. Is this possible?
>
> The interval doesn't matter very much. The touchpad should not be sending
> any data at all when nothing is happening.
A longer interval would solve it in some way:
I could get constantly new temperature update (each second or more) and if
the touchpad is touch, I can reduce the interval to the normal settings.
> Does the touchpad use the HID protocol? If it does, did you remember to
> send a Set-Idle request to prevent the device from sending any data when
> no events have occurred?
I will check!
For explanation:
I want this to reduce the power consumption by letting the processor enter
the power-saving states more often (and longer).
Regards
Sven
--
Sven Anders <[EMAIL PROTECTED]> () Ascii Ribbon Campaign
/\ Support plain text e-mail
ANDURAS service solutions AG
Innstra?e 71 - 94036 Passau - Germany
Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55
Rechtsform: Aktiengesellschaft - Sitz: Passau - Amtsgericht Passau HRB 6032
Mitglieder des Vorstands: Sven Anders, Marcus Junker
Vorsitzender des Aufsichtsrats: Dipl. Kfm. Thomas Tra"ger
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
