Re: [PATCH 1/1]: input: add support for VirtualBox touchscreen emulation to the Lifebook driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Feb 23, 2010 at 09:55:33PM +0100, Michael Thayer wrote:
> Hello Dmitry,
> 
> Thanks for your comments!
> 
> Le mardi 23 février 2010 à 09:58 -0800, Dmitry Torokhov a écrit :
> > On Tue, Feb 23, 2010 at 12:13:35PM +0100, Michael Thayer wrote:
> > > This patch adds support for VirtualBox touchscreen emulation to the Lifebook
> > >  input driver.
> [snip]
> > I am wondering if it is a good idea to piggy-back on Lifebook. The
> > devices are sufficiently different with Lifebook really having 2
> > separate devices (touchscreen and either regular external mouse or a
> > touchpad) and VirtualBox having asingle device that looks like a pointer
> > (not a touchscreen since pointer moves constantly, not while "touching")
> > with absolute coordinates reporting.
> 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 (I could imagine us adding Solaris support at a later point,
> and it would be nice to see "little" OSes picking up support independently).

But the virtual mouse is not a touchscreen or a tablet, it behaves
differently.

> 
> 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?

> (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?

>  Of course,
> as you point out, we have the unused touch bit, but the device works nicely
> sending co-ordinates without "touching", and having at least nominal touch
> functionality is rather a prerequisite for emulating a touch screen.

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.

> 
> > I think it would be better if we had separate protocol module for that.
> > [snip]
> Separate module as in separate driver, or changes to the actual (PS/2 extension)
> protocol?  If the second, then what did you have in mind?

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.

>  One protocol change
> I could think of, other than the thing with the buttons, would be a magic knock
> rather than DMI matching, as that would let others piggy-back on us.  Not a big
> advantage for us of course, but it might be one for you.

I'd rather you stick with DMI, piggybackers can simply add their DMI
strings. The reason I do not want to have magic knock is that it may
disturb real hardware probing which is already quite fragile.

> 
> > This issue should be fixed in the recent kernels.
> Ah, I failed to see that (I was working against the Ubuntu Lucid kernel
> after checking that there were no more recent changes to lifebook.c).
> Is the fix in psmouse-base.c?
> 

Among others.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux