Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

SuperHID v2

Downsides of SuperHID v1

SuperHID v1 extends the Linux HID gadget with multitouch stuff.
Using the gadget subsystem, originally designed for real hardware, implies having to simulate and drive a ton of hardware:

  • A USB host controller (HCD)
  • A USB device controller (UCD), along with its endpoints and the glue to the HCD
  • A USB device that "plugs" to a UCD

The resulting fake device is then passed to a guest using the PV USB backend/frontend.

In the proof-of-concept, the dummy_hcd kernel module is used as an HCD+UCD, with the critical limitation that it supports only 1 USB device, with no easy way to extend to multiple devices.

In general, the gadget subsystem is not meant to be used like that. Gadgets are for "slave" USB devices, not hosts...

New ideas

In the current scheme, we spend a lot of effort and resource to simulate a "real" device, when in the end it gets "virtualized"...

The main idea for making it simpler would be to stop using the gadget subsystem, and just plug SuperHID somewhere in the PV USB mechanism. The frontends just bring up "fake" devices anyway!

I see two ways of doing this:

  • usbback could be modified to be able to use a special kernel module in place of real USB devices. That way, the frontends would need no modification, but that implies understanding and modifying the huge mess that is usbback...
  • A separate USB backend could be written, using some of the guts of usbback as a starting point. That new backend would talk to SuperHID instead of real devices. That means not having to mess with usbback, but the frontends may have to be modified to be able to deal with multiple PV USB backends...

The second approach seems to make the most sense to me, so that's what I'm looking at.

Here's a picture that compares the two designs:

SuperHID v1

Introduction

Some HID background could be useful to understand the core of SuperHID.

When using SuperHID, the input follows that path:

Device (HID)
  v
Linux (HID->Event)
  v
input_server (Event)
  v
SuperHID plugin (Event->HID)
  v
SuperHID driver (HID)
  v
SuperHID fake device (HID->USB)

Then, passing the superhid fake device through to any guest gives it all the input we want.

Highlights

  • No code needed in the guest VM
  • Multi-touch works in Microsoft Windows 8, and any other pv-usb-enabled guest
  • All the input still goes through input_server, which gives total control over what event goes to which VM
  • No labels