> From: James Simmons <[EMAIL PROTECTED]>
> Date: Wed, 23 Jan 2002 12:18:00 -0800 (PST)
> To: Jim Gettys <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED],
> [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: Re: Touchscreen driver, Xinput extension, input device interface,
> etc....
> -----
> > We're planning on using Vojtech's new input mechanism (most generally
> > fleshed out for USB devices, but it's always been intended for general
> > use) to deal with input devices in the future on Linux, and will be
> > retargeting the iPAQ's touch screen driver interface to this interface.
>
> Yeah!!!!! I know some time ago I attempted to rewrite the h3600
> touchscreen to the input api. Unfortunely I never had enough time to
> complete it.
If you have code lying around, donations greatfully accepted and might
get it done faster.
>
> > We plan to use the low level event interface provided, rather than the
> > more cooked (typically for backward compatibility) interfaces, as it looks
> > like it should greatly help with coming devices on desktop systems and
> > support of the X Input extension. We should no longer have to teach X
> > about one device at a time, rather the kernel provides more abstract
> > interfaces for classes of devices we can leverage.
>
> Great. Because for 2.5.X will input devices will be moved over to this
> api. This includes every keyboard as well. The dave jones tree already has
> a bunch of devices converted over to the input api. I'm pushing maintainers
> on other platforms to port their keyboards over.
> As a side note also the console system will under go changes since it
> will be input api based internally. This means raw/medium keyboard mode
> will go away for linux. It will be considered obsolete. Use the event
> interface instead. This will also allow use to use a X server without
> needing a console system. You can use the event interface without a
> console system. It just the console system WILL need the input api.
> I look forward to the day when we will have direct input for OpenGL for
> real time respond with games.
Yup.
Exactly.
> > o The input interface will be widened in two minor ways:
> > 1) user programs will be able to set the calibration data.
> > (either make the EVIOCGABS ioctl RW or add a new ioctl).
> > Pavel doesn't care which, but, of course, reserves the
> > right to change it if it isn't what he wants :-).
>
> What? I think you misunderstood the use of EVIOCGABS. That returns the
> range of values the hardware can generate. Those values are used
> internally in the input system to filter out junk. Sometimes hardware can
> give you errous data so those fields filter that.
Could be I misunderstood; the documentation is somewhat fragmentary. But
knowing the ranges gives you what you need to rescale data.
>
> > 2) user programs (e.g. calibration programs) will signal
> > to clients of the input interfaces the calibration has
> > been changed by writing a reset event (the input stuff
> > broadcasts this to all clients using the new input
> > event mechanism). Clients that care to respond to new
> > calibration data will then read the calibration data and
> > rescale.
>
> Again are you dealing with hardware that would reprogram itself to change
> the range of values it would produce for events?
Not at the moment. Care to name an example? And why reprogram it when
the client is rescaling?
>
> > o new input devices will get signalled to the X server via
> > the hotplug mechanism, precise details TBD. It is there where
> > policy will get set as to whether an input device gets handed
> > to X or left alone to be used directly by other programs; we hope
> > leveraging the work that is going on there on setting policy
> > on how new devices get recognized/installed/configured.
>
> It shoudn't matter for read incoming events if a bunch of programs, X and
> other things, would use the event interface at the same time. It is
> writing that does matter. Then we get into a per process state that is
> stored.
There is the policy item of whether such devices should appear in the
X server's view of input devices at all. So some policy of whether
input devices get handed off to the X server when plugged in needs to go
somewhere, and that, IMHO, is not the X server itself, as X is not the
only consumer of input devcies.
And there are still insane people who want to run true multihead
(several monitors, X servers, keyboards and mice for more than one users).
- Jim
--
Jim Gettys
Cambridge Research Laboratory
Compaq Computer Corporation
[EMAIL PROTECTED]
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
