Re: usbtouchscreen: Add support for Zytronic capacitive touchscreen

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Tue, Jan 13, 2009 at 09:29:18AM +0000, Daniel Silverstone wrote:
> On Mon, 2009-01-12 at 21:33 -0800, Dmitry Torokhov wrote:
> > > > > +	/* Always service the USB devices irq not just when the input device is
> > > > > +	 * open.
> > > > > +	 */
> > > > > +	int irq_always;
> > > > Why is this needed?
> > > Some devices (E.g. specifically this one) expect their interrupt
> > > endpoints to always be serviced. In this case, the device has an
> > > on-board watchdog and will reboot (disconnect and reconnecting to the
> > > USB) if it is not serviced in a timely fashion.
> > So what happens if driver was unloaded or there was no driver loaded at
> > all? Is this device constantly connecting and reconnecting?
> 
> As I understand it; yes. (Some bits of hardware really are hideous
> things) Indeed if the driver fails to load quickly enough, the device
> might disconnect/reconnect before the driver can get hold of it.
> 

Geez... you sure it wasn't just broken device/batch?

> > > > > +		dev->touch = 1;
> > > > > +		dev->press = 1;
> > > > Since the device does not report real pressure readings don't try to
> > > > fake it, reporting touch is enough.
> > > I believe that this is because some userland libraries, particularly
> > > tslib, require the pressure reading in order to believe the device is
> > > functioning usefully. Specifically, consider plugins/input-raw of
> > > tslib's source package which uses pressure rather than touch.
> > Yes, I am aware of TSLIB case and I am telling everyone who submits
> > touchscreen drivers that they need to fix it. The policy is that
> > kernel should not generate fake events but present as accurate state
> > of hardware as possible.
> 
> Unfortunately it's often harder to get people to change their userland
> than their kernel. It seems a pity to make the driver less useful during
> any longer-term effort to fix TSLIB. If acceptance of this patch is
> predicated on removing that then I guess we'll have to discuss it
> amongst ourselves and try and work out what we'd rather do. Is removing
> the fake pressure report a requirement or a would-like?
> 

I just checked TSLIB and the change to recognize devices that do not
report pressure was applied 2 months ago so everything should work fine
now. I do not think that we need to implement workarounds in newly
added drivers just because users are not willing to upgrade their
TSLIB installation.

-- 
Dmitry