Touchscreen doesn't work after karmic->lucid upgrade

Bug #537801 reported by Mario Limonciello on 2010-03-12
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
udev (Ubuntu)
Medium
Unassigned
xf86-input-wacom (Ubuntu)
Medium
Timo Aaltonen
xserver-xorg-input-evdev (Ubuntu)
Undecided
Robert Hooker

Bug Description

The touchscreen was working fine in karmic, but i just dist-upgraded to lucid a few days ago and it doesn't work now.

ProblemType: Bug
Architecture: i386
Date: Thu Mar 11 19:45:35 2010
DistroRelease: Ubuntu 10.04
DkmsStatus:

MachineType: Dell Inc. Latitude 2100
Package: xserver-xorg-input-wacom 1:0.10.3+20100109-1ubuntu2
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-16-generic root=UUID=8595c17f-1fef-4c55-b757-57c07b6e1450 ro quiet splash
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-16.25-generic
SourcePackage: xf86-input-wacom
Uname: Linux 2.6.32-16-generic i686
dmi.bios.date: 04/08/2009
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A00
dmi.board.name: 0W785N
dmi.board.vendor: Dell Inc.
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA00:bd04/08/2009:svnDellInc.:pnLatitude2100:pvr:rvnDellInc.:rn0W785N:rvr:cvnDellInc.:ct8:cvr:
dmi.product.name: Latitude 2100
dmi.sys.vendor: Dell Inc.
system:
 distro: Ubuntu
 codename: lucid
 architecture: i686
 kernel: 2.6.32-16-generic

Mario Limonciello (superm1) wrote :
Robert Hooker (sarvatt) on 2010-03-12
affects: xf86-input-wacom (Ubuntu) → xf86-input-evtouch (Ubuntu)
Changed in xf86-input-evtouch (Ubuntu):
status: New → Confirmed
Robert Hooker (sarvatt) wrote :

Looked into it a bit more.. It looks like the udev is tagging it as ID_INPUT_TABLET=1 because its a resistive touchscreen not a capacitive one with BTN_TOUCH, and our /lib/udev/rules.d/65-xorg-evdev.rules is missing a catchall for tablet devices -

ENV{ID_INPUT_TABLET}=="?*", ENV{x11_driver}="evdev"

currently only the wacom udev rule is matching ID_INPUT_TABLET and its universally loading wacom which should be tightened down a bit to only load with a wacom vendor ID (serial tablets from other vendors are handled before the catchall) to accompany this change.

affects: xf86-input-evtouch (Ubuntu) → xserver-xorg-input-evdev (Ubuntu)
Martin Pitt (pitti) wrote :

Adding an udev task to fix input_id here. I'll investigate the udev dump in detail, I imight come up with some further questions later on.

Changed in xserver-xorg-input-evdev (Ubuntu):
assignee: nobody → Martin Pitt (pitti)
Changed in udev (Ubuntu):
assignee: nobody → Martin Pitt (pitti)
importance: Undecided → Medium
status: New → Triaged
Martin Pitt (pitti) wrote :

Robert,

so the wacom driver isn't meant to drive all tablets, just a few of them? As long as the wacom rules still have

  ACTION=="add|change", SUBSYSTEM=="input", ENV{ID_INPUT_TABLET}=="?*", ENV{x11_driver}="wacom"

then an evdev catchall won't do anything?

Changed in xserver-xorg-input-evdev (Ubuntu):
assignee: Martin Pitt (pitti) → nobody
Robert Hooker (sarvatt) wrote :

Right, it does handle some non wacom tablets and will need to also match n-trig id's at some point but the non-wacom ones it handles are accounted for by the pnp subsystem matches at the top. The evdev rules change was already sponsored by bryce for me but we're in freeze at the moment. Wacom will need changing to something like this I believe (syntax is probably incorrect)?

ACTION=="add|change", SUBSYSTEM=="input", ENV{ID_INPUT_TABLET}=="?*", ATTRS{idVendor}=="056a", ENV{x11_driver}="wacom

This is reliant on evdev actually being able to drive his device which needs testing though but it should, and I mentioned to him in IRC that he'll have to keep 69-xserver-xorg-input-wacom.rules out of the way for now to test it if evdev works before we look at making evtouch work which previously handled it in karmic but used hal fdi's and hasn't been ported to udev.

Robert Hooker (sarvatt) wrote :

Also I'm not sure if the udev test needs updating, it assigns it ID_INPUT_TABLET correctly because it does report having a BTN_TOOL_PEN or BTN_STYLUS.

Bryce Harrington (bryce) on 2010-03-18
tags: added: karmic
Martin Pitt (pitti) wrote :

> Also I'm not sure if the udev test needs updating, it assigns it ID_INPUT_TABLET correctly because it does report having a BTN_TOOL_PEN or BTN_STYLUS.

But if it isn't a tablet, and really a touchscreen, it should get fixed. Mario, any chance you could attach the output of lshal, so that we can compare?

Martin Pitt (pitti) wrote :

> ACTION=="add|change", SUBSYSTEM=="input", ENV{ID_INPUT_TABLET}=="?*", ATTRS{idVendor}=="056a", ENV{x11_driver}="wacom"
>
> This is reliant on evdev actually being able to drive his device

I'm confused -- if the driver is set to "wacom", why does evdev need to be able to drive this?

Martin Pitt (pitti) wrote :

Ah, I just noticed your xserver-xorg-input-evdev upload, thus setting this to fix committed.

So is treating this touchscreen as a "tablet" actually semantically correct, and we're really just missing setting a driver for it?

Changed in xserver-xorg-input-evdev (Ubuntu):
assignee: nobody → Robert Hooker (sarvatt)
status: Confirmed → Fix Committed
Changed in udev (Ubuntu):
status: Triaged → Incomplete
Robert Hooker (sarvatt) wrote :

It's kind of a semantics problem, it's really a resistive tablet overlay with stylus support connected internally over USB instead of being an actual touchscreen with BTN_TOUCH events. I'm pretty sure evdev will work properly will the device though, and fedora is also assigning evdev initially for ID_INPUT_TABLET devices. Looks like it was just an oversight that that part was missing from the evdev rules. There are proprietary drivers specifically for this device from the manufacturer with xserver 1.7 support that look like they would work, but dell distributes an older version for 9.04/9.10 only - http://www.ideacom.com.tw/DR_UTS6680.htm

Here is the old fdi for this device under evtouch in karmic-

<?xml version="1.0" encoding="UTF-8"?> <!-- -*- SGML -*- -->

<deviceinfo version="0.2">
  <device>
    <match key="info.product" contains="IDEACOM">
      <match key="info.product" contains="IDC 6680">
        <match key="info.capabilities" contains="input.touchpad">
          <merge key="input.x11_driver" type="string">evtouch</merge>
          <merge key="input.x11_options.reportingmode" type="string">raw</merge>
          <merge key="input.x11_options.taptimer" type="string">50</merge>
          <merge key="input.x11_options.longtouchtimer" type="string">30</merge>
          <merge key="input.x11_options.movelimit" type="string">15</merge>
          <merge key="input.x11_options.emulate3buttons" type="string">true</merge>
          <merge key="input.x11_options.emulate3timeout" type="string">50</merge>

          <merge key="input.x11_options.minx" type="string">460</merge>
          <merge key="input.x11_options.maxx" type="string">7920</merge>
          <merge key="input.x11_options.miny" type="string">750</merge>
          <merge key="input.x11_options.maxy" type="string">7660</merge>
        </match>
      </match>
    </match>
  </device>
</deviceinfo>

if evdev doesn't work, xserver-xorg-input-evtouch currently looks like it doesn't work properly unless someone has a manual xorg.conf set up for the device. it only installs a rule to create a symlink for evtouch devices and needs fixing to also load evtouch for the devices and set the default options, and our old fdi's need porting to that udev rule as well.

Martin Pitt (pitti) wrote :

Thanks for the explanation. So input_id seems to do the right thing, and the uploaded -evdev should get the device to work mostly (and we just might need to ship more rules for fine-tuning the options)

Changed in udev (Ubuntu):
assignee: Martin Pitt (pitti) → nobody
status: Incomplete → Invalid
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xserver-xorg-input-evdev - 1:2.3.2-3ubuntu2

---------------
xserver-xorg-input-evdev (1:2.3.2-3ubuntu2) lucid; urgency=low

  * 65-xorg-evdev.rules: only set x11_driver for event devices, and also
    extend to work for tablet devices. Fixes part of LP: #537801
 -- Robert Hooker <email address hidden> Mon, 15 Mar 2010 21:05:29 -0400

Changed in xserver-xorg-input-evdev (Ubuntu):
status: Fix Committed → Fix Released
Mario Limonciello (superm1) wrote :

Now that the freeze has been lifted I upgraded to the new -evdev. Things don't work, but if I move 69-xserver-xorg-input-wacom.rules out of the way and reboot, they work fine with -evdev. So I'd say those rules need to be modified to not be picking up this panel still.

Robert Hooker (sarvatt) wrote :

Indeed that is the intended behavior and what I meant by fixes part of in the changelog, its good to hear evdev does work though! tjaalton asked me to assign a bug to him reminding him to lock down the wacom rules so they aren't loaded for all tablet devices so I'm doing that here.

Changed in xf86-input-wacom (Ubuntu):
assignee: nobody → Timo Aaltonen (tjaalton)
importance: Undecided → Medium
status: New → Confirmed

On Sat, Mar 20, 2010 at 04:38:14PM -0000, Robert Hooker wrote:
> Indeed that is the intended behavior and what I meant by fixes part of
> in the changelog, its good to hear evdev does work though! tjaalton
> asked me to assign a bug to him reminding him to lock down the wacom
> rules so they aren't loaded for all tablet devices so I'm doing that
> here.

Hi guys, I'm a bit fuzzy on the status of this bug - it sounds like
there's still some work needed? Or is it working properly now?

Timo Aaltonen (tjaalton) wrote :

A new wacom udev rule (or a config snippet, eheh) is needed to let evdev handle it. I've got it in a ppa where it failed to build though, forgot to autoreconf it before building the source package.

Timo Aaltonen (tjaalton) wrote :

current wacom has that change.

Changed in xf86-input-wacom (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers