Stop using hal for input devices

Registered by Martin Pitt

In our vendetta to move away from hal, handling input devices is one of the last items. (See

This is being discussed upstream (, and a patch is being reviewed. We should contribute to this to test/fix the migration.

Blueprint information

Bryce Harrington
Martin Pitt
Needs approval
Martin Pitt
Series goal:
Accepted for lucid
Milestone target:
milestone icon lucid-alpha-2
Started by
Martin Pitt
Completed by
Martin Pitt

Related branches



Work items for lucid-alpha-2:
[tjaalton] update our packages to Debian experimental 1.7.1 (which has jcristau's udev branch applied): DONE
[pitti] Create and test udev rules for evdev/keyboard: DONE
[pitti] Create and test udev rules for synaptics: DONE
[pitti] Create udev prober for input device classification: DONE
[pitti] write release note (migration of custom fdi files): DONE
[bryceharrington] write test plan at DONE
[bryceharrington] Write release notes about -wacom being broken: DONE

Work items for lucid-alpha-3:
[bryceharrington] Upgrade to new wacom driver: DONE
[albertomilone] test wacom: DONE
[ogra] test touch screens: DONE

bryce 2009-11-25: I tried the udev patches against our current xserver, but they don't apply and look like it'd be non-trivial to port them. So I'm going to hold off until we have xserver 1.7 merged in, which should be simpler to put these patches against. That work is going on in debian presently and we should have it in ubuntu within a couple weeks I think. I stuck the (non-building) package into this ppa:

pitti, 2009-11-26: I applied the patches against current xorg-edgers, and they work great with the udev rules I proposed above (not included in the package, this was just a quick try):

pitti, 2009-11-27: Julien applied the udev branch and above udev rules to the debian experimental git now. This should be ready for merging into Lucid.

pitti, 2009-11-30: udev input_id created and committed upstream
pitti, 2009-12-01: above is in lucid now.
pitti, 2009-12-07: New landed, hal dropped from CDs

pitti, 2009-12-17: Wrote documentation and migration guide:
bryce, 2009-12-17: I drafted a start at a touchscreen test plan at however it could benefit from another set of eyes and maybe some elaboration. Please take a look and give some wiki edits. :-)
pitti, 2009-12-18: it looks well to me, but then again I have never had a touch screen. I'll ping Oliver
bryce, 2009-12-21: Well, then let's call the task done. If it's found to be missing anything later it can be added. It's wiki.

albertomilone, 2009-12-23: tested with a wacom tablet (CTE-430 Sapphire). I'm get only one input device in Lucid when I plug in my tablet when I should get 1 for the cursor, 1 for the eraser and 1 for the stylus (each one uses the driver as a separate device). Furthermore the cursor seems to hang for a while after I click with the stylus.

pitti, 2009-12-23; Thanks, Alberto! However, -wacom still needs to be updated, it is not expected to work right now. I suppose that your system currently uses evdev for the tablet? Or are you running a newer local wacom version?

bryce, 2009-01-06: As of this moment we do not have any indication that upstream is near to a release for the new driver. Also, we can't simply grab a snapshot, because it's not just a newer version but a whole new package (named xf86-input-wacom instead of wacom-tools), and will need packaging work (ideally by Debian) and so on. I have added a known-issue about the unavailability of wacom to the release notes, and moved the tasks to alpha-3. It is true that evdev detects the tablet itself, but with the stylus, etc. not available it's hardly workable, so the testing will need redone after the new driver is in Ubuntu.

albertomilone, 2010-01-26: tested with a wacom tablet (CTE-430 Sapphire) with the new driver in Lucid. Everything seems to work correctly (stylus, eraser, pressure and the buttons). I'm getting 3 input devices in xinput i.e. 1 for the cursor, 1 for the eraser and 1 for the stylus.

bryce, 2010-01-03: we've had good feedback from other people testing this; can we mark this one done?



Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.