[PATCH 1/1]: input: add support for VirtualBox touchscreen emulation to the Lifebook driver
Michael Thayer
input driver.
The device will be present as an extension to the PS/2 mouse emulation in the
next major release of VirtualBox. We chose to emulate the Lifebook touchscreen
mainly in order to simplify in-kernel support, as the Lifebook driver is active
by default in most kernel configurations. We had to extend the protocol
slightly as we wish to provide five mouse buttons and a two-way scroll wheel to
virtual guest systems, and we tried to do this in the most non-intrusive way
possible with regard to the current driver, which is the reason for the slightly
unusual handling of mouse buttons three to five.
Most changes in the driver are conditional on the VirtualBox DMI string being
found. A notable exception is the removal of the keybit fields for the left,
right and middle buttons for the first device. The current X.Org evdev driver
was seeing these and treating the device as a touchpad instead of a touchscreen.
I also tested this with a vanilla Ubuntu Lucid live CD while emulating the
original device and presenting a suitable DMI string.
Signed-off-by: Michael Thayer <michael...@sun.com>
--- lifebook.c 2010-02-23 12:01:32.941643681 +0100
+++ lifebook-vbox.c 2010-02-23 11:44:57.831664482 +0100
@@ -1,6 +1,8 @@
/*
* Fujitsu B-series Lifebook PS/2 TouchScreen driver
+ * Also used for Oracle VirtualBox mouse integration
*
+ * Copyright (c) 2010 Oracle. All rights reserved.
* Copyright (c) 2005 Vojtech Pavlik <voj...@suse.cz>
* Copyright (c) 2005 Kenan Esau <kenan...@conan.de>
*
@@ -41,6 +43,15 @@ static int lifebook_set_6byte_proto(cons
return 0;
}
+static bool lifebook_use_vbox_proto;
+
+static int lifebook_set_vbox_proto(const struct dmi_system_id *d)
+{
+ lifebook_use_6byte_proto = true;
+ lifebook_use_vbox_proto = true;
+ return 0;
+}
+
static const struct dmi_system_id lifebook_dmi_table[] = {
{
.ident = "FLORA-ie 55mi",
@@ -115,6 +126,13 @@ static const struct dmi_system_id lifebo
DMI_MATCH(DMI_PRODUCT_NAME, "LifeBook B142"),
},
},
+ {
+ .ident = "VirtualBox",
+ .matches = {
+ DMI_MATCH(DMI_PRODUCT_NAME, "VirtualBox"),
+ },
+ .callback = lifebook_set_vbox_proto,
+ },
{ }
};
@@ -180,6 +198,21 @@ static psmouse_ret_t lifebook_process_by
((packet[0] & 0x10) ? packet[1] - 256 : packet[1]));
input_report_rel(dev2, REL_Y,
-(int)((packet[0] & 0x20) ? packet[2] - 256 : packet[2]));
+ if (lifebook_use_vbox_proto && !(packet[0] & 0x04)) {
+ unsigned btn = (packet[0] >> 6);
+
+ input_report_key(dev2, BTN_MIDDLE, btn == 1);
+ input_report_key(dev2, BTN_SIDE, btn == 2);
+ input_report_key(dev2, BTN_EXTRA, btn == 3);
+ }
+ if (lifebook_use_vbox_proto && (packet[0] & 0x04)) {
+ unsigned wheel = (packet[0] >> 6);
+
+ input_report_rel(dev2, REL_WHEEL,
+ (wheel == 0) - (wheel == 1));
+ input_report_rel(dev2, REL_HWHEEL,
+ (wheel == 2) - (wheel == 3));
+ }
}
input_report_key(dev2, BTN_LEFT, packet[0] & 0x01);
input_report_key(dev2, BTN_RIGHT, packet[0] & 0x02);
@@ -200,11 +233,17 @@ static int lifebook_absolute_mode(struct
/*
Enable absolute output -- ps2_command fails always but if
you leave this call out the touchsreen will never send
- absolute coordinates
+ absolute coordinates.
+
+ Note that old versions of VirtualBox which didn't emulate the
+ touchscreen also failed to return an error here, so if we are
+ running inside VirtualBox, we actually have to make sure that
+ the command fails!
*/
param = lifebook_use_6byte_proto ? 0x08 : 0x07;
- ps2_command(ps2dev, ¶m, PSMOUSE_CMD_SETRES);
-
+ if (!ps2_command(ps2dev, ¶m, PSMOUSE_CMD_SETRES) &&
+ lifebook_use_vbox_proto)
+ return -1;
return 0;
}
@@ -251,11 +290,14 @@ int lifebook_detect(struct psmouse *psmo
return -1;
if (set_properties) {
- psmouse->vendor = "Fujitsu";
- psmouse->name = "Lifebook TouchScreen";
+ psmouse->vendor = !lifebook_use_vbox_proto ? "Fujitsu" :
+ "VirtualBox";
+ psmouse->name = !lifebook_use_vbox_proto ?
+ "Lifebook TouchScreen" :
+ "Mouse Integration" ;
}
- return 0;
+ return 0;
}
static int lifebook_create_relative_device(struct psmouse *psmouse)
@@ -274,7 +316,8 @@ static int lifebook_create_relative_devi
"%s/input1", psmouse->ps2dev.serio->phys);
dev2->phys = priv->phys;
- dev2->name = "PS/2 Touchpad";
+ dev2->name = !lifebook_use_vbox_proto ? "PS/2 Touchpad" :
+ "Virtual PS/2 Mouse";
dev2->id.bustype = BUS_I8042;
dev2->id.vendor = 0x0002;
dev2->id.product = PSMOUSE_LIFEBOOK;
@@ -285,6 +328,13 @@ static int lifebook_create_relative_devi
dev2->relbit[BIT_WORD(REL_X)] = BIT_MASK(REL_X) | BIT_MASK(REL_Y);
dev2->keybit[BIT_WORD(BTN_LEFT)] = BIT_MASK(BTN_LEFT) |
BIT_MASK(BTN_RIGHT);
+ if (lifebook_use_vbox_proto) {
+ __set_bit(BTN_MIDDLE, dev2->keybit);
+ __set_bit(REL_WHEEL, dev2->relbit);
+ __set_bit(REL_HWHEEL, dev2->relbit);
+ __set_bit(BTN_SIDE, dev2->keybit);
+ __set_bit(BTN_EXTRA, dev2->keybit);
+ }
error = input_register_device(priv->dev2);
if (error)
@@ -310,6 +360,14 @@ int lifebook_init(struct psmouse *psmous
dev1->evbit[0] = BIT_MASK(EV_ABS) | BIT_MASK(EV_KEY);
dev1->relbit[0] = 0;
dev1->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
+ /*
+ The psmouse-base driver enables these bits, but if the X.Org
+ evdev driver sees them it thinks we are a touchpad, not a
+ touchscreen.
+ */
+ psmouse->dev->keybit[BIT_WORD(BTN_MOUSE)] &= ~(BIT_MASK(BTN_LEFT) |
+ BIT_MASK(BTN_MIDDLE) | BIT_MASK(BTN_RIGHT));
+
input_set_abs_params(dev1, ABS_X, 0, max_coord, 0, 0);
input_set_abs_params(dev1, ABS_Y, 0, max_coord, 0, 0);
--
Sun Microsystems GmbH Michael Thayer
Werkstrasse 24 VirtualBox engineer
71384 Weinstadt, Germany mailto:michael...@sun.com
Sitz der Gesellschaft:
Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Haering
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Dmitry Torokhov
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.
>
> The device will be present as an extension to the PS/2 mouse emulation in the
> next major release of VirtualBox. We chose to emulate the Lifebook touchscreen
> mainly in order to simplify in-kernel support, as the Lifebook driver is active
> by default in most kernel configurations. We had to extend the protocol
> slightly as we wish to provide five mouse buttons and a two-way scroll wheel to
> virtual guest systems, and we tried to do this in the most non-intrusive way
> possible with regard to the current driver, which is the reason for the slightly
> unusual handling of mouse buttons three to five.
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 think it would be better if we had separate protocol module for that.
The fact that Lifebook is enabled in many current configurations should
not affect the decision - current distributions will have to chose to
backport the change and if they decide to do so will activate the config
option; users compiling their own kernels will decide if they want it.
Also, VirualBox may be popular enough to condition the new option on
EMBEDDED so that it is active by default.
>
> Most changes in the driver are conditional on the VirtualBox DMI string being
> found. A notable exception is the removal of the keybit fields for the left,
> right and middle buttons for the first device.
This issue should be fixed in the recent kernels.
--
Dmitry
Michael Thayer
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).
The two devices also make sense for us on the one hand because xf86-input-evdev
currently only understands absolute devices without mouse buttons (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. 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.
> 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? 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.
> 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?
Regards,
Michael
--
Sun Microsystems GmbH Michael Thayer
Werkstrasse 24 VirtualBox engineer
71384 Weinstadt, Germany mailto:michael...@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 Torokhov
> Hello Dmitry,
>
> Thanks for your comments!
>
> > 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
Michael Thayer
> 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
> But the virtual mouse is not a touchscreen or a tablet, it behaves
> differently.
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". 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.
> > 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".
> > (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 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...@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 Torokhov
> 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?
--
Dmitry
Michael Thayer
Le jeudi 25 février 2010 à 02:17 -0800, Dmitry Torokhov a écrit :
> 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.
We decided in the end to emulate a USB tablet, as some other virtualisers do.
It works well out of the box with recent Linux distributions, and while older
ones recognise it as a touchpad (in fact they use it through /dev/input/mice),
it still provides a reasonable user experience until the user has installed our
guest drivers.
Thank you again for your comments and assistance.
Regards,
Michael
--
Sun Microsystems GmbH Michael Thayer
Werkstrasse 24 VirtualBox engineer
71384 Weinstadt, Germany mailto:michael...@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 Torokhov
> Hello Dmitry,
>
> > On Wed, Feb 24, 2010 at 12:46:29PM +0100, Michael Thayer wrote:
> > > > 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.
> We decided in the end to emulate a USB tablet, as some other virtualisers do.
> It works well out of the box with recent Linux distributions, and while older
> ones recognise it as a touchpad (in fact they use it through /dev/input/mice),
Yes, mousedev will provide workable approximation of standard mouse for
a device that provides absolute events. BTW, the fact that data from a
device is available from /dev/input/mice does not mean that device was
recognized as a mouse, a touchpad or something else. It just means that
kernel is able to approximate device as a standard PS/2 Expolorer mouse.
> it still provides a reasonable user experience until the user has installed our
> guest drivers.
It is your call but I would much rather if you worked on fixeng evdev to
work with your virtual device rather than having to install a new X
driver and going through the hoops trying to detect which one should be
used on a particular box. At least on Linux...
Thanks.
--
Dmitry
Michael Thayer
> On Tue, Mar 02, 2010 at 09:44:48PM +0100, Michael Thayer wrote:
> > it still provides a reasonable user experience until the user has installed our
> > guest drivers.
>
> It is your call but I would much rather if you worked on fixeng evdev to
> work with your virtual device rather than having to install a new X
> driver and going through the hoops trying to detect which one should be
> used on a particular box. At least on Linux...
shipping X.Org Server 1.4 and earlier, and those distributions are no longer
going to get that sort of update (in those cases in which they are still
getting updates at all). Legacy support if you like.
Thanks again,
Michael
--
Sun Microsystems GmbH Michael Thayer
Werkstrasse 24 VirtualBox engineer
71384 Weinstadt, Germany mailto:michael...@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 Torokhov
> Le mardi 02 mars 2010 � 13:28 -0800, Dmitry Torokhov a �crit :
> > On Tue, Mar 02, 2010 at 09:44:48PM +0100, Michael Thayer wrote:
> > > it still provides a reasonable user experience until the user has installed our
> > > guest drivers.
> >
> > It is your call but I would much rather if you worked on fixeng evdev to
> > work with your virtual device rather than having to install a new X
> > driver and going through the hoops trying to detect which one should be
> > used on a particular box. At least on Linux...
> That wouldn't really help us much here, as we are talking about distributions
> shipping X.Org Server 1.4 and earlier, and those distributions are no longer
> going to get that sort of update (in those cases in which they are still
> getting updates at all). Legacy support if you like.
>
You need to distribute something... Or do these older distros already
include your guest drivers?
--
Dmitry
Michael Thayer
> On Tue, Mar 02, 2010 at 11:00:19PM +0100, Michael Thayer wrote:
> > > It is your call but I would much rather if you worked on fixeng evdev to
> > > work with your virtual device rather than having to install a new X
> > > driver and going through the hoops trying to detect which one should be
> > > used on a particular box. At least on Linux...
> > That wouldn't really help us much here, as we are talking about distributions
> > shipping X.Org Server 1.4 and earlier, and those distributions are no longer
> > going to get that sort of update (in those cases in which they are still
> > getting updates at all). Legacy support if you like.
> You need to distribute something... Or do these older distros already
> include your guest drivers?
We provide the drivers for those distributions (as well as a couple of other
things like tools for clipboard integration with the host, or seamless desktop
integration) as part of the VirtualBox package (and yes, we do jump through
hoops to install them :) ). A couple of distributions do actually install them
by default (openSUSE, Pardus), but that is a bit of a mixed blessing for us, as
the versions installed are usually not the most recent, and it is hard for us to
update them.
Regards,
Michael
--
Sun Microsystems GmbH Michael Thayer
Werkstrasse 24 VirtualBox engineer
71384 Weinstadt, Germany mailto:michael...@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
--