[ubuntu-x] Fwd: Wacom tablets, TabletPC and Xorg support for Ubuntu 9.04 (Jaunty)
bryce at canonical.com
Wed Nov 12 20:07:16 GMT 2008
On Tue, Nov 11, 2008 at 09:50:59PM +0100, Lo?c Martin wrote:
> I've done a mockup at
> https://help.ubuntu.com/community/Wacom/PropertiesMockup and I'm
> attaching a compressed Inkscape SVG. Only the first
Nice quick work! And props for doing it in Inkscape. :-)
It's a good blue sky design. For Jaunty I think we should shoot for
a subset of that concept.
> I also started a thread for discussing this possible tool on
> linuxwacom-discuss (so we don't mix discussion about the tool and
I see they're already complaining about us forking, when no one's even
committed yet to putting time into wacom. ;-)
Seriously though, we do need to take care not to get too ahead of
ourselves. Realistically, we're a small crew already spread thin across
a LOT of packages, and likely will only have a small amount of developer
time that will be available, so we need to focus it on a tightly scoped
task, that improves the situation for users, but doesn't make us bite
off more than we can chew.
I think the idea of an x-kit based tool to just paste in the respective
lines into xorg.conf fits that bill. It's 100% just stuff we already
know how to do, it should be pretty simple, and won't interfere with
upstream's work, and so once they have the hal/fdi stuff all perfected
we can drop the x-kit tool without guilt. If that's achieved by Jaunty,
great; if not, no worries we can still ship something that will give a
small improvement for wacom users.
Beyond that, I think we definitely have ideas on how to make a better
config tool, however the last thing we want to do is to invest time to
try to help improve things for wacom and just end up making upstream
irritated at us us. ;-)
If anyone gets motivated to go beyond this, excellent. But we should
take care to not let the scope get too far beyond what we can deliver.
Worst case would be to rip out existing solutions but fail to perfect a
new solution, and end up actually making things harder/broken for users
than what we have now. (Or equally hard and broken, but just in new
and more exciting ways.)
We should also take care to keep in mind that if we make an xorg.conf
modification tool for Jaunty that has a lot of bells and whistles, then
when we cut over to an new upstream tool in Jaunty+1 or whenever, if it
does not have provide all the same bells and whistles, upset users will
be sending us regression reports. Sometimes upstream won't want to
implement all those things, or it won't be possible for some technical
reason, and I don't think we can count on having the time ourselves
later on to reimplement them on top of the new tool. So being very
conservative in what features we provide in our temporary xorg.conf tool
is probably wise. It's better to have a user longing for a missing
feature, than a user angry about a regression in a feature they used to
enjoy; they won't care that the implementation had been just a temporary
> It was probably a mistake, the wacom lines could have been present in
> xorg.conf and commented out (for the sake of KDE users I believe), and
No it was not done merely for KDE users.
Historically, lots of people complained about the static wacom config.
See #42553 in particular. KDE was hit hard, but it caused ample
confusion with bug reporters on GNOME too. Yet to me, all the issues
were essentially cosmetic; nothing was *broken*. I decided to leave
things as is.
Months later, henrik contacted me regarding problems the wacom entries
caused for an accessibility application (an on-screen keyboard I
think). I think it was actually segfaulting the app, plus imposing a
pretty severe accessibility issue.
I don't generally like the idea of breaking things for one set of users
in order to fix something for another set, however I justified it in
that wacom users were able to use their system even without editing
xorg.conf to enable their device, however disabled users were unable to
use their system at all until they'd edited xorg.conf to remove it. The
inconvenience of the latter user was greater than that of the former.
I commented the lines rather than removed them so we weren't leaving
wacom folks totally in the cold, but knew that'd be a temporary solution
only, given the objective of emptying out xorg.conf. I had hoped that
by the time we switched to input-hotplug in Intrepid, that wacom would
be good to go. But no, and here we are.
> Any work on that tool isn't going to be wasted, for the sole reason that
> the Gnome desktop has nothing planned for that (they've got keyboard
> properties, mouse properties, but nothing for Tablets or AFAIK
Let's keep in mind, that just because GNOME has no tool in development
doesn't mean our work would be accepted automatically. ;-) We've been
burned on this before. It's better to do nothing, than do something
that really ought to go upstream, but that upstream won't take.
But I do think that having a (simple) backup alternative is smart and
wise for a case where the upstream efforts run late and won't be
perfected in time for our release.
> If an Ubuntu developer can program the tool, I can go ahead and detail
> (on the wiki) exactly what options are necessary for what model of
> tablet/TabletPC, ask our users for the models I'm not sure and do the
> liason with upstream for double check. And organise some testing.
So long as we focus only on static settings that can be pasted into
xorg.conf, that should be fine. Like, a dropdown to select the wacom
tablet model (or 'generic' for the old commented-out settings), buttons
to Apply or Cancel, and a popup dialog to tell the user to restart for
the settings to take effect (plus relevant error dialogs as
appropriate). Maybe a couple other widgets would be okay, but if we
start going to multiple-tabs, that's probably a clue we're straying too
far into stuff that really needs to wait for the upstream solution.
> So if you tell me you can handle the GUI programming and the
> parsing/editing of either xorg.conf or/and the fdi (for choosing only
x-kit can do the parsing/editing of xorg.conf easily. A one-page dialog
like I described above, plus a database of static tablet configs to
paste into xorg.conf should be a reasonably doable amount of work.
That also gets our wacom support back to Feisty-era, and even slightly
better, for a pretty minimal amount of time commitment. Users would
still complain about having to hack on xorg.conf, but sometimes you give
a man a fish and he just asks why you didn't cook it for him. ;-)
> P.S: Bryce, for the 0.8.1.6 SRU in Intrepid do you still want me to
> start the process, or is there a way we'll get some 0.8.1.6 packages to
> get some tests before?
In general, the release team prefers to see SRUs of individual patches
rather than entire packages. Requests for the latter are almost always
rejected. I asked about if that would hold true in this particular case
but didn't get an answer, so have to assume it would.
Since that's pretty time consuming, and since I'm going to be gone the
next several weeks (Ubuntu OEM on-site, UDS, and interspersed holidays),
unless you know of specific patches we need to have, maybe it'd be
easiest if you just put in a ubuntu-backports request for this one.
More information about the Ubuntu-x