Touchscreen doesn't work after karmic->lucid upgrade

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.

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.

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?

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.

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.

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

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

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?

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.

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)

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

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.

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.

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?

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.

current wacom has that change.