Hello, again!
Well, with lots of debugging enabled, I got to some more details about the
non working DMC TSC-10 USB Touchscreen:
(see also: http://lkml.org/lkml/2007/6/26/228 )
Whenever I plug in the TSC-10 I get the following output
hub 3-0:1.0: state 7 ports 4 chg 0000 evt 0004
ehci_hcd 0000:00:14.2: GetStatus port 2 status 001403 POWER sig=k CSC CONNECT
hub 3-0:1.0: port 2, status 0501, change 0001, 480 Mb/s
hub 3-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x501
ehci_hcd 0000:00:14.2: port 2 low speed --> companion
ehci_hcd 0000:00:14.2: GetStatus port 2 status 003402 POWER OWNER sig=k CSC
hub 3-0:1.0: state 7 ports 4 chg 0000 evt 0004
hub 2-0:1.0: state 7 ports 2 chg 0000 evt 0002
ohci_hcd 0000:00:14.1: GetStatus roothub.portstatus [0] = 0x00010301 CSC LSDA PPS CCS
hub 2-0:1.0: port 1, status 0301, change 0001, 1.5 Mb/s
hub 2-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x301
ohci_hcd 0000:00:14.1: GetStatus roothub.portstatus [0] = 0x00100303 PRSC LSDA PPS PES CCS
usb 2-1: new low speed USB device using ohci_hcd and address 16
ohci_hcd 0000:00:14.1: GetStatus roothub.portstatus [0] = 0x00100303 PRSC LSDA PPS PES CCS
usb 2-1: default language 0x0054
usb 2-1: wrong descriptor type 00 for string 1 ("TSC-10 DM")
usb 2-1: new device strings: Mfr=1, Product=0, SerialNumber=0
usb 2-1: Manufacturer: TSC-10 DM
usb 2-1: uevent
usb 2-1: usb_probe_device
usb 2-1: configuration #1 chosen from 1 choice
usb 2-1: adding 2-1:1.0 (config #1, interface 0)
usb 2-1:1.0: uevent
usbtouchscreen 2-1:1.0: usb_probe_interface
usbtouchscreen 2-1:1.0: usb_probe_interface - got id
drivers/usb/input/usbtouchscreen.c: usbtouch_probe - type->init() failed, err: -19
drivers/usb/core/inode.c: creating file '016'
hub 2-0:1.0: state 7 ports 2 chg 0000 evt 0002
And when I unplug it, it cleans up the device properly:
hub 2-0:1.0: state 7 ports 2 chg 0000 evt 0002
ohci_hcd 0000:00:14.1: GetStatus roothub.portstatus [0] = 0x00010100 CSC PPS
hub 2-0:1.0: port 1, status 0100, change 0001, 12 Mb/s
usb 2-1: USB disconnect, address 16
usb 2-1: unregistering device
usb 2-1: usb_disable_device nuking all URBs
usb 2-1: unregistering interface 2-1:1.0
usbdev2.16_ep81: ep_device_release called for usbdev2.16_ep81
usb 2-1:1.0: uevent
usbdev2.16_ep00: ep_device_release called for usbdev2.16_ep00
usb 2-1: uevent
hub 2-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x100
Any ideas of what's wrong here before I have to start to
dig deeper in the source?!
The touchscreen controller chip is a TSC-103 088 F3J0
it has no EEPROM attached. (which should be optional to save
calibration data)
The USB controller is a Philips ISP1563BM PCI Host Controller
DateCode April-2006.
The same problem appears with 2.6.21.5 and 2.6.20.1-ubuntu-something
on x86 platform.
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Stra?e 45/1
Linhof Werksgel?nde
D-81379 M?nchen
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
Hi,
On 6/27/07, Clemens Koller <[email protected]> wrote:
> drivers/usb/input/usbtouchscreen.c: usbtouch_probe - type->init() failed, err: -19
dmc_tsc10_init() returns -ENODEV (-19) when device responds with
something other than 0x06 0x00 to the "reset" and "set rate" commands.
It would be interesting to see what your touchscreen responses are.
--
Dmitry
Hello, Dimitry!
Dmitry Torokhov schrieb:
> On 6/27/07, Clemens Koller <[email protected]> wrote:
>> drivers/usb/input/usbtouchscreen.c: usbtouch_probe - type->init()
>> failed, err: -19
>
> dmc_tsc10_init() returns -ENODEV (-19) when device responds with
> something other than 0x06 0x00 to the "reset" and "set rate" commands.
> It would be interesting to see what your touchscreen responses are.
Yes, thank you!
I just had a look into the datasheet.
(tsc10usb_pi_e.pdf, Rev. 1.2 from November 1, 2005)
and I will need more debugging info to the dmc_tsc10_init()...
As I wrote, I am using the TSC-103 without EEPROM.
(I can add one if it's of any use.)
The PanelID is 0 (pin 3 [SEL1] is low), so it's the "first"
device on the bus.
What exact chip version and EEPROM configuration do you use?
I guess there are different firmware releases for the different
TSC-10* devices which behave... well... different. :-(
Regards,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Stra?e 45/1
Linhof Werksgel?nde
D-81379 M?nchen
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
On 6/27/07, Clemens Koller <[email protected]> wrote:
> Hello, Dimitry!
>
> Dmitry Torokhov schrieb:
> > On 6/27/07, Clemens Koller <[email protected]> wrote:
> >> drivers/usb/input/usbtouchscreen.c: usbtouch_probe - type->init()
> >> failed, err: -19
> >
> > dmc_tsc10_init() returns -ENODEV (-19) when device responds with
> > something other than 0x06 0x00 to the "reset" and "set rate" commands.
> > It would be interesting to see what your touchscreen responses are.
>
> Yes, thank you!
> I just had a look into the datasheet.
> (tsc10usb_pi_e.pdf, Rev. 1.2 from November 1, 2005)
> and I will need more debugging info to the dmc_tsc10_init()...
>
> As I wrote, I am using the TSC-103 without EEPROM.
> (I can add one if it's of any use.)
> The PanelID is 0 (pin 3 [SEL1] is low), so it's the "first"
> device on the bus.
>
> What exact chip version and EEPROM configuration do you use?
I don't.
> I guess there are different firmware releases for the different
> TSC-10* devices which behave... well... different. :-(
>
Could be, although according to that data sheet 0x0600 is ACK for both
touchschreens with and without EEPROMs.
I think most of the changes fro USB touchscreen came in from Daniel
Ritz, let's try CCing him...
--
Dmitry
Hello, Dimitry!
Dmitry Torokhov schrieb:
> Hi,
>
> On 6/27/07, Clemens Koller <[email protected]> wrote:
>> drivers/usb/input/usbtouchscreen.c: usbtouch_probe - type->init()
>> failed, err: -19
>
> dmc_tsc10_init() returns -ENODEV (-19) when device responds with
> something other than 0x06 0x00 to the "reset" and "set rate" commands.
> It would be interesting to see what your touchscreen responses are.
I found the problem:
After the reset, I got a 0x06 0x00 back, which is fine.
But when the driver sets the coordinate output rate, the TSC-103
answered 0x15 0x01 which means that the TSC-10 is used with an
EEPROM but the EEPROM data is empty (which is correct).
In that case the driver should at least continue to allow
initialization of the EEPROM later on. But as we don't have the
infrastructure to write the calibration data back to EEPROM, only
touch screen manufacturers which want to use the EEPROM will run into
that problem...
The same is true if there is no EEPROM present but the EEPROM is enabled.
Anyway, I disabled my EEPROM by pulling the SEL4 pin high because I don't
need/want it (yet).
So, it *works for me* but just for future reference:
The DMC TSC-10 driver doesn't start, when it has an empty (new)
EEPROM attached.
I started to do some more error handling, but it's propably not
worth doing so if the driver(s) has only limited functionality (and
no userspace app using it).
Thank you,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Stra?e 45/1
Linhof Werksgel?nde
D-81379 M?nchen
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
> The same is true if there is no EEPROM present but the EEPROM
> is enabled. Anyway, I disabled my EEPROM by pulling the SEL4
> pin high because I don't need/want it (yet).
The same is done by my hardware guy. In my case, there is no
EEPROM attached ... but he didn't pull up this pin up, until I
found out what happend.
For the EEPROM: I actually don't care if the calibration data is
written somewhere in my filesystem or in some proprietary
EEPROM. If you create gadgets with unwritable filesystems, e.g.
cramfs, then you might care. But I didn't, and therefore didn't
bother implementing any support for calibration on the
driver-level. I'm doing that completely from userspace.
> I started to do some more error handling, but it's propably
> not worth doing so if the driver(s) has only limited
> functionality (and no userspace app using it).
Who says that the driver has no user space app? All touchscreen
events that you get are exported via /dev/input/eventX to user
space and there are plenty of apps that utilize this info.
I wrote a (company inside) tool that reads /dev/input/eventXX,
calibrates them and injects those events into X11 via the XTest
extension. But for newer X.Org release you can also use
xserver-input-event driver. My approach has just the benefit
that I can "SIGHUP" my driver any time to re-calibrate, I don't
need to restart X for this, which is cumbersome.
So, please add error handling and post your patch :-)
> After the reset, I got a 0x06 0x00 back, which is fine.
>
> But when the driver sets the coordinate output rate, the
> TSC-103 answered 0x15 0x01 which means that the TSC-10 is used
> with an EEPROM but the EEPROM data is empty (which is
> correct).
>
> In that case the driver should at least continue to allow
> initialization of the EEPROM later on.
No, I don't think so. Not in it's current form.
Currently, usbtouchscreen doesn't have any means to initialize an
EEPROM. And in the absence of such a possibility, you need other
means to accomplish your task. The current behavior provides you
with this "plan b":
If you set the rate and that doesn't work because no EEPROM is
there, the driver fails. While doing it, it will release the
device.
This brings in the opportunity to access the touchscreen
controller from userspace, e.g. with libusb, and write the
EEPROM. After this, reboot, and be happy. Because now the device
would act correctly on the "set rate" command and would be
usable.