callout example script for touchscreens

[Daniel Stone]

Hi,

On Tue, Sep 02, 2008 at 06:19:37PM +0200, ext Danny Kukawka wrote:
> As I already told you HAL don't do anything with or for wacom devices. Check 
> the HAL upstream git repo! Everything you need to setup Xorg device should go 
> into the related driver package.

Yes, agreed, to some extent.

> And btw. IMO it's a stupid idea at all to do X configuration in HAL. Xorg 
> should have it own config store or config backend where all the options get 
> stored/handled. Especially calibration data (which is never generic and isn't 
> stored statically in HAL, you have to set it again and again after each 
> startup or for each new X session) or e.g. Wacom devices (which have 2, 3 or 
> more X device sections for a input device) are an example why X should handle 
> this itself (it can ask HAL for info about the hardware, but please not 
> more).

I don't see how calibration data is an example of why X should bear the
responsibility _at all_, nor how the number of input devices comes into
it.

You'll note when the set of patches were initially posted and merged, I
was pained to not add an input.x11 option, and instead only
input.x11_driver, as that is the only sensible option.  Even then, I
agree that's a dumb option to require, and we should do it better.  Mea
culpa for lacking the appropriate insight.

However, the rest isn't 'X configuration', it's 'things you need to
make the best use of this device'.  This isn't just X.  It may sound
weird coming from an X.Org developer[0], but we'd like for X.Org to
stop being the entire system.  Some people are going to want to run
without a windowing system for whatever reason (and many already do, cf.
direct framebuffer apps, or with a different windowing system, e.g.
DirectFB), and they should be supported to, inasmuch as it makes sense.

'Which model of keyboard is this' is not X configuration, but simple
description of your hardware.  Hence why I believe things like this
should go into HAL.  Touchscreens frequently require calibration, and
are utterly useless without them: so either we say that Xorg is the only
thing that will ever deal with touchscreens, or we admit that this is
data that should be shared.

input.xkb was motivated by exactly that: cxkb exists to use the only
complete set of keyboard mappings on the console, and though it is not
in wide use currently, I hope and expect that changes soon.  I'm doing
a lot of work on XKB upstream that I hope will benefit cxkb, and at
that point, we just have to convince Fedora to move.  Bam.

input.x11_options is rather an abuse, and the current scattershot
selection of options and variation between drivers (as well as some
options that are completely unnecessary) is merely a reflection of
current unpleasant reality, than where we'll be in a year or even
six months.  I was against its inclusion because it felt too much like
defeat, but code talks and it's not something I've been able to spend
time on in the past few months, so in the end it got merged despite
my philosophical objections.

> > imho pointing out the needed driver for a HW is the responsibility of
> > hal while applying settings should likely be part of the driver package
> > itself am i so wrong here ?
> 
> Since the settings and parameters can differ between the drivers the driver 
> should contains everything that's needed (incl. callouts, scripts, fdi, ... 
> whatever).

We're fixing that, and will have a standard set of parameters (see
above).

I know it's not ideal right now, but please trust me that it's only
going to get better -- not worse -- and that I'm unhappy with the
current state of affairs too.  I don't know what form or shape HAL is
going to take in the future and how this relates to us, but this seems
like knowledge that should be in an infinitely better spot than a crappy
config file everyone wishes would not exist.  That situation is good for
us in terms of having a captive audience of the entire free desktop, but
not really healthy for free software, nor even us as a whole[1].

Cheers,
Daniel

[0]: If it makes you less suspicious, just imagine I'm trying to reduce
     my own problem space as much as possible.
[1]: While sheer disgust at our own codebase and design has carried us a
     very long way so far, having actual competition is the best
     motivator for improvement.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/hal/attachments/20080905/ba6e3d62/attachment.pgp