[lkml]   [2010]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/1]: input: add support for VirtualBox touchscreen emulation to the Lifebook driver
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

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2010-02-24 11:05    [W:0.044 / U:1.972 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site