current wacom has that change.
** Changed in: xf86-input-wacom (Ubuntu)
Status: Confirmed => Fix Released
--
Touchscreen doesn't work after karmic->lucid upgrade
https://bugs.launchpad.net/bugs/537801
You received this bug notification because you are a member of Ubuntu
Bugs, which is sub
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.
--
Touchscreen doesn't work after karmic->lucid upgrade
https://bugs.launchpad.net/bugs/537801
You
On Sat, Mar 20, 2010 at 04:38:14PM -, 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
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:
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.
** Also affects: xf86-input
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
-
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)
Status: Incomplete => Invalid
** Changed in: udev (Ubuntu)
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
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)
Status: Confirme
> 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?
--
Touch
> 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
c
** Tags added: karmic
--
Touchscreen doesn't work after karmic->lucid upgrade
https://bugs.launchpad.net/bugs/537801
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.
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.
--
Touchscreen doesn't work after karmic->lucid upgrade
https://bugs.launchpad.net/bugs/537801
You received this bug notification because you are
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
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-evd
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: (unassigned) => Martin Pitt (pitti)
** Also affects: udev (Ubuntu)
Importance: Undecided
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
** Package changed: xf86-input-wacom (Ubuntu) => xf86-input-evtouch
(Ubuntu)
** Changed in: xf86-input-evtouch (Ubuntu)
Status: New => Confirmed
--
Touchscreen doesn't work after karmic->lucid upgrade
https://bugs.launchpad.net/bugs/537801
You received this bug notification because you ar
** Attachment added: "BootDmesg.txt"
http://launchpadlibrarian.net/40842487/BootDmesg.txt
** Attachment added: "CurrentDmesg.txt"
http://launchpadlibrarian.net/40842488/CurrentDmesg.txt
** Attachment added: "Dependencies.txt"
http://launchpadlibrarian.net/40842489/Dependencies.txt
** A
19 matches
Mail list logo
