linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Michael Thayer <Michael.Thayer@Sun.COM>
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1]: input: add support for VirtualBox touchscreen emulation to the Lifebook driver
Date: Thu, 25 Feb 2010 02:17:05 -0800	[thread overview]
Message-ID: <20100225101705.GF10823@core.coreip.homeip.net> (raw)
In-Reply-To: <1267011989.2831.30.camel@michael-laptop>

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@sun.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-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2010-02-25 10:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-23 11:13 [PATCH 1/1]: input: add support for VirtualBox touchscreen emulation to the Lifebook driver Michael Thayer
2010-02-23 17:58 ` Dmitry Torokhov
2010-02-23 20:55   ` Michael Thayer
2010-02-24 10:02     ` Dmitry Torokhov
2010-02-24 11:46       ` Michael Thayer
2010-02-25 10:17         ` Dmitry Torokhov [this message]
2010-03-02 20:44           ` Michael Thayer
2010-03-02 21:28             ` Dmitry Torokhov
2010-03-02 22:00               ` Michael Thayer
2010-03-02 22:39                 ` Dmitry Torokhov
2010-03-02 23:13                   ` Michael Thayer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100225101705.GF10823@core.coreip.homeip.net \
    --to=dmitry.torokhov@gmail.com \
    --cc=Michael.Thayer@Sun.COM \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).