[ubuntu-x] Fwd: Wacom tablets, TabletPC and Xorg support for Ubuntu 9.04 (Jaunty)

[Loïc Martin]

Bryce Harrington a écrit :
> 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.  :-)

And props for doing Inkscape :)

> It's a good blue sky design.  For Jaunty I think we should shoot for
> a subset of that concept.

Tell me if I need to write a blueprint and what else should be done.

> 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.  ;-)

They wouldn't. We're not touching their code, and we're using their
options. I think Ron is more irritated by the idea someone would set an
untested/unstable method such as the .fdi on users. It's maybe more like
a parent-like reaction "What are they doing to their kids!" than
anything personal. It's his job in Debian that's being used in the first
place, so it's also "How can he use the nice belt I gave him to flog his
kids?"

> 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
> development hack.

Upstream doesn't have anything in the works for that at the moment. When
Ubuntu switches to a different method than xorg.conf, there'll be
nothing for setting the options, and some tablets and all TabletPc are
useless without calibration.

I'm interested in getting upstream involved for that reason - maybe the
programmer on the Ubuntu side won't have the time to do much, but if we
can talk about it with others we'll get more chances somebody can pick
up the code and provide a tool for the post xorg.conf era (and, may I
say, the 21th century).

It's also my opinion that upstream (LWP, but also Gnome) should have
provided a GUI for configuring xorg.conf years ago. It's not a rant
against developers, they have a busy schedule, but nevertheless I prefer
admiting where we fail. Our users deserve to know that we also don't
consider the situation as acceptable. They can then pester Wacom or
their hw manufacturer for what it's worth. Giving an idea of what we'd
like for the future (even if it takes a few years) can also motivate
some to contribute - so if I keep updating the mockup don't take it as a
pressure on the devs, just that if we get everything as streamlined as
possible the devs can concentrate on the code.

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

Thanks for the clarifications. I'm sure the information was passed on
somewhere, but we users failed to get it, and would have been far
readier to accept the situation if we hadn't.

>> 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
>> joysticks).
> 
> 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.

LWP doesn't have anything in the work. And I don't know if anybody is
expecting Gnome to put tablets on their schedule. They'd need a drawing
program then. Touch, sure, it's oh so hype, but it won't do tablet users
any good, unless we fancy drawing with a stick.

If we use xorg.conf for Jaunty there's no need for more options -
wacomcpl works quite well, except on multihead (only really affect
Cintiq tablets).

If the programmer has the time for simple options, the ones on Fig2. are
an easy target (the 4 slides result in a single line with 4 numbers in it).

The most useful for TabletPC would be stylus calibration - and I've got
no clue if it would take some time to set up. The option is simple, but
you need to set two crosses on the screen (top right / bottom left) and
record the position of the stylus when the tip is pressed.

Button configuration is more work indeed, but I'll keep working on the
mockup because that's an aspect wacomcpl needs to work on.

As for worries about regressions when we don't use the xorg.conf method
anymore, either upstream won't have anything ready and we're going to
alienate a portion of our userbase, or they'll have done something
supporting all their options. Them doing the job that requires 99% of
the time but failing to implement a few more boxes doesn't make much
sense. wacomcpl isn't the most ergonomic GUI, but you get all the options.

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

The different configs aren't rocket science, so I could provide the
tablet configs if it can help.

> 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.  ;-)

It brings it far better than Feisty, since serial Tablets and TabletPC
will also be supported, along with the pad. Along with wacomcpl in the
repos, you get everything you could need - for an xorg.conf setup.

I think what hurt with Intrepid is the fact the information about the
changes didn't reach our users. I've seen improvements on the Release
Notes, and I think we're headed in the right direction, but those notes
still aren't obvious for 99% of the users, who don't read anything more
than the Release announcement before booting the LiveCD (Release notes
in the installer, with a prominent Regression part would be an idea).

Since LWP is still with the xorg.conf method, and none of the
documentation was done with the newer xorg.conf in mind (as the one in
Intrepid),  I fail to see how normal users would have been able to fix
their setup. Nobody even seem to be using the .fdi method by default
AFAIU (Debian doesn't use it according to Ron, and isn't planning that
on the short term).

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

I'll keep track of Jaunty's, but it's still 0.8.1.4 at the moment.
Debian is at 0.8.1.6, so the sync is still ahead.
Thanks,
Loïc