udev rules should be installed by default

[Soren Hauberg]

This package comes with a set of udev rules (69-touchscreen.rules) for creating the device /dev/input/evtouch_event. If you want to use the evtouch driver today the procedure is as follows:
  1) Figure out you have to install the evtouch driver.
  2) Install the driver.
  3) Figure out you have to setup udev to create a device.
  4) Setup udev.
  5) Configure X and calibrate the monitor.
Steps 1, 3, and 5 are the hard ones. If you install the udev rules by default (when you install the xserver-xorg-input-evtouch package), steps 3 and 4 will disappear, which will make it a lot easier to setup a touch screen. I don't really see the downside to doing this.

[Eric Drechsel (ericdrex)]

definitely needed. I have enough gripes about the evtouch package that I would like to volunteer to help update it.

evtouch doesn't currently build with intrepid (at least I couldn't build it), and we're unlikely to get this in hardy. So this task depends on updating evtouch to work with the xorg that is in intrepid. The upstream code isn't in a public repository, I sent a query to the upstream maintainer about status.

[Eric Drechsel (ericdrex)]

looks like the issue that I mentioned above was fixed in #254848

[Bryce Harrington (bryce)]

Hi hauberg,

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with the latest development release of Ubuntu? (ISOs are available from cdimage.ubuntu.com)

If it remains an issue, could you also attach a new /var/log/Xorg.0.log?
Thanks in advance.

The output of lspci -vvnn would also be worth having.

[Soren Hauberg (hauberg)]

Unfortunately, I no longer have access to the touch screen I was using
when I filed the bug. In the mean time some things have changed, while I
don't know about other things.

== Things that I don't believe has changed ==

The kernel still uses udev and I doubt that'll change for quite some
time. Some touch screens are recognized by the kernel, and these will
use evdev to report user input to X11. This means that kernel-recognized
touch screens will appear as /dev/input/eventN, where N is some integer.
However, the value of N will change when the machine is rebooted.

If a user decides to use the 'evtouch' driver for X11, she will need
some set of udev rules to make sure that the device always appears with
the same name. Since 'evtouch' is not installed by default in Ubuntu,
the user has to manually install. I think it is fair to assume that
users that choose to install 'evtouch' has the hardware and want it to
be as easy as possible to configure it. So it still makes perfect sense
to install the udev rules when 'evtouch' is installed. I don't believe
anything has changed here.

== Things that have changed ==
With Peter Hutterer I have updated the 'evdev' driver for X11 (which
used by default in Ubuntu, I believe) to also support touch screens.
With the latest release of the 'evdev' driver all the basic stuff (such
as run-time calibration) is supported. So, these days it should be
possible to get a working touch screen setup without installing
'evtouch' at all. But I no longer have the hardware needed to verify
this.

== Conclusion ==
I still makes sense to install the udev rules that come with 'evtouch'
when 'evtouch' is installed. These udev rules shouldn't be installed by
default in Ubuntu, as the 'evdev' driver should just-work, but if the
user chooses to install 'evtouch' it should be as easy as possible to
configure it.

Søren

P.S. If you're working on touch screen support, then the last missing
piece of the puzzle really seems to be calibration. A while back I
posted some nice Cairo-based software for this on the xorg developer
list. It still needs some updates to work with recent 'evdev' drivers,
but the hard stuff is done.

[Eric Drechsel (ericdrex)]

Just a follow-up on Soren's comment, I have been testing xinput_calibrator [1], it is excellect, with a goal of supporting calibration of all drivers, and export to udev, xorg, xinput command, hal. This should be integrated in Ubuntu.

[1] http://github.com/tias/xinput_calibrator

[Bryce Harrington (bryce)]

[This is an automatic notification.]

Hi Soren,

This bug was reported against an earlier version of Ubuntu, can you
test if it still occurs on Lucid?

Please note we also provide technical support for older versions of
Ubuntu, but not in the bug tracker. Instead, to raise the issue through
normal support channels, please see:

    http://www.ubuntu.com/support

If you are the original reporter and can still reproduce the issue on
Lucid, please run the following command to refresh the report:

  apport-collect 242590

If you are not the original reporter, please file a new bug report, so
we can work with you as the original reporter instead (you can reference
bug 242590 in your report if you think it may be related):

  ubuntu-bug xorg

If by chance you can no longer reproduce the issue on Lucid or if you
feel it is no longer relevant, please mark the bug report 'Fix Released'
or 'Invalid' as appropriate, at the following URL:

  https://bugs.launchpad.net/ubuntu/+bug/242590

[Soren Hauberg (hauberg)]

I don't know how to reply to that. I realise that people are busy and that you have to resort to automated replies sometimes, but this reply does not make sense to me in the context of the bug report.

I reported this bug two years ago, but (as I have previously stated) I no longer have access to the hardware needed, so I cannot do as you request. I am, however, quite certain that the bug report is still valid as it simply concerns the installation of the package and not the actual driver.

[Bryce Harrington (bryce)]

Eventually I think -evtouch is going to go away in favor of just using -evdev. We can keep this bug report open until then, even though the hardware is no longer available for testing.

[Eric Drechsel (ericdrex)]

i have been using evdev for a few releases now, on a variety of fujitsu and panasonic notebooks. it seems to do everything evtouch does, so I'd vote to close this.

[Soren Hauberg (hauberg)]

@eric
I did the initial implementation of touchscreen support in 'evdev', so I'm glad that works for you :-) It should, however, be said that 'evtouch' does quite a bit more than 'evdev' (it has more options).

I don't think this bug should be closed, instead it should be fixed :-) Basically, this bug is about if the user decides to install a package then it should be properly configured by default.

As I don't work with touch screens anymore, this bug has little relevance to me, but I still think it would be better to simply fix it, rather than doing nothing...

[Eric Drechsel (ericdrex)]

great job Soren! It's nice to have a unified driver, much easier to support etc.

i was just looking through the evdev and evtouch code and trying to
understand if evtouch has some sort of right-click emulation via
LONG_TOUCH, which is the only other thing I would miss in evdev
(although it might not be that usable anyway)

On Wed, May 5, 2010 at 10:30 PM, Soren Hauberg <email address hidden> wrote:
> @eric
> I did the initial implementation of touchscreen support in 'evdev', so I'm glad that works for you :-) It should, however, be said that 'evtouch' does quite a bit more than 'evdev' (it has more options).
>
> I don't think this bug should be closed, instead it should be fixed :-)
> Basically, this bug is about if the user decides to install a package
> then it should be properly configured by default.
>
> As I don't work with touch screens anymore, this bug has little
> relevance to me, but I still think it would be better to simply fix it,
> rather than doing nothing...
>
> --
> udev rules should be installed by default
> https://bugs.launchpad.net/bugs/242590
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Timo Aaltonen (tjaalton)]

Yes, evdev supports touchscreens now, and evtouch doesn't even build, so it's going to be removed from the archive. And because of that, this bug can be closed.