Message-ID: <20100225101705.GF10823@core.coreip.homeip.net>
Date:	Thu, 25 Feb 2010 02:17:05 -0800
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Michael Thayer <Michael.Thayer@....COM>
Cc:	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1]: input: add support for VirtualBox touchscreen
 emulation to the Lifebook driver

On Wed, Feb 24, 2010 at 12:46:29PM +0100, Michael Thayer wrote:
> Le mercredi 24 février 2010 à 02:02 -0800, Dmitry Torokhov a écrit :
> > On Tue, Feb 23, 2010 at 09:55:33PM +0100, Michael Thayer wrote:
> > > I'm not sure, if we ended up doing a completely new device, how different it
> > > would end up being.  Emulating a touchscreen or a tablet makes sense for us as
> > > these are both something known, which will work with existing systems without
> > > too much tweaking
> > > [snip]
> > But the virtual mouse is not a touchscreen or a tablet, it behaves
> > differently.
> What would you suggest emulating that exists in the real world?

There are not many real devices that have teh same characteristics as
virtual mouse generating absolute coordinates. Umm, the closest would be
a wacom tablet when used with its own mouse.

>  And might a
> tablet not be better than a touchscreen, given that it doesn't just have a
> binary concept of "touch or not", but a pressure axis as well?  We could report
> "pen on but zero pressure".

No, tablet still has the property that movement ceases when you remove
object touching the device from proximity. In your case you will be
always sending coordinates and expect userspace react to them regardless
of button/tool/etc state.

>  I take your point (below) about not relying on
> behaviour that doesn't correspond to real devices like being able to send
> position data without BTN_TOUCH being held down.

I think the cleaniest would be to send ABS_X/ABS_Y nad buttons. Xen does
this so I'd expect evdev being able to handle it.

> 
> > > The two devices also make sense for us on the one hand because xf86-input-evdev
> > > currently only understands absolute devices without mouse buttons
> > 
> > Hmm, I scanned through it and I did not see anything specifically
> > removing mouse buttons from absolute devices there... Is it still valid
> > for the recent version of evdev driver?
> Sorry, I have to correct myself there.  It assumes that an absolute device with
> a "BTN_TOUCH" and mouse buttons and no pen is a touchpad and not a touchscreen.
> Function "EvdevProbe()", search for "Found absolute touchpad".

And if you remove BTN_TOUCH (which does not make sense in your case)
then it won't be saying that.

> 
> > > (yes I know,
> > > we could send them patches too if we had too, but we would rather not patch the
> > > whole world :) ) and on the other because it makes it easy for us to switch
> > > between absolute and relative event reporting, which is a big plus.
> > 
> > Why is this a big plus? Also, can't evdev handle devices reporting both
> > relative and absolute events?
> We sometimes want to switch to relative event reporting to e.g. let people play
> games which are controlled using the mouse.  Don't ask :)  I can check again,
> but I think that xf86-input-evdev ignores relative axes if a device supports
> absolute ones.

I don't think so, could you please re-test it?

> I do feel that having two devices from it's point of view is
> a safer bet here, rather than trying something fancier.
> 
> > You are relying on the fact that currently userspace components rely on
> > drivers not sending coordinates data without touch; as soon as userspace
> > (evdev) starts validating it and ignoring coordinate events without
> > ABS_PRESSURE or BTN_TOUCH you'll be toast.
> Point taken.  See above.
> 
> > > > I think it would be better if we had separate protocol module for that.
> > [snip]
> > First, create a separate protocol handler (module similar to
> > lifebook.c), allocate protocol number, something like PSMOUSE_VBPS, and
> > plumb it into psmouse-base.c in the same fashion othe protocol handlers
> > do it.
> Sure, I can copy lifebook.c and make the necessary modifications.  I will wait
> for your answers/comments on the above though (particularly the first bit)
> before starting.
> 
> Thanks again.
> 
> Regards,
> 
> Michael
> -- 
> Sun Microsystems GmbH        Michael Thayer
> Werkstrasse 24               VirtualBox engineer
> 71384 Weinstadt, Germany     mailto:michael.thayer@....com
> 
> Sitz der Gesellschaft:
> Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten
> Amtsgericht Muenchen: HRB 161028
> Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels
> Vorsitzender des Aufsichtsrates: Martin Haering
> 

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists