this should be extended to video drivers as well allowing you to
dynamically adjust that. I believe THomas Winischofer has done
something simialr with his sisctl utility and the sis driver, although
I haven't really looked to closely at how that works yet.
Alex
--- "Bryan W. Headley" <[EMAIL PROTECTED]> wrote:
> Joe Krahn Sez,
> > What we _really_ need is an update to the XINPUT protocol.
>
> > I started experimenting with ideas on this. I had hoped some of
> > this work would happen once Jim Gettys became the XINPUT
> > leader, but I suspect it will be 5.x material for XFree86,
> > since the XFree86 XINPUT code needs a serious re-write
> > with things like hot-pluggable devices and USB, and some
> > form of access to OS-driven input, at least for some systems.
>
> > In addition, there is an intent to support devices connected
> > through a socket. This would allow connection of remote
> > devices, or connection to a userland daemon for unusual
> > or experimental devices. Right now, crashing a developmental
> > device driver crashes X.
>
> > My idea for XINPUT controls is that XChangeDeviceControl
> > should use an XAtom for a control type, and generalized
> > int/short/long for the control data, like WindowProperties.
> > This can exactly fit the current command syntax if we
> > replace int with an XAtom. For backwards compatibility,
> > the few very small enum values are essentially certain
> > not to collide with a useful device Atom.
>
>
> I generally agree with the XAtom approach. Do you know who's working
> on
> this? E.g., is Jim Gettys?
>
> What I want to see (I think) is a four-tiered approach:
>
> 1) I would want the parameter passing api to match the behavior gone
> through while parsing the XF86Config file. Under this system, there's
>
> only one parameter-to-internal struct parser/validator.
>
> 2) I would want the userland interface to permit a complex reply
> structure. As complex in fact as a section in the XF86Config-4 file.
>
> 3) Much like what Citron's doing now, I'd like the ability to send
> 'clientData', which has nothing to do with driver parameter
> upload/downloads. It might be some kind of clientdata that describes
> your handwriting to some input device that has its own OCR
>
> 4) I would like to,
> a) Load a driver 'in media res' for a hardware device not
> originally
> plugged in, and perhaps not defined originally in the XF86Config-4.
> b) Destructively remove a driver from the memory pool of the X
> Server.
> c) Put a driver in an inactive input state. The hotplugged device
> is
> unplugged and is expected to be plugged in later.
> d) Return an inactive driver to activity (due to hotplug event).
> Inference is that device is plugged into a different device driver.
>
> Things that bother me but I haven't decided on a course yet,
>
> 1) The whole XI_deviceType information. For example, if you look at
> the Aiptek driver, technically it is a XI_TABLET driver, but I really
>
> allocate three pseudo-devices for a Stylus, Cursor and Eraser, that
> all
> share the same file descriptor. XI_STYLUS, XI_CURSOR, ...? How many
> XI_*
> are there, and really, I would like to know that driver 'X' is a
> Cursor
> associated with a Tablet related to a driver like Aiptek or Wacom.
> A way around it is a "secret handshake" API, but that really stinks.
>
> 2) Drivers should be able to send off events at their own discretion.
>
> E.g., in Linux/HID/USB land, an X driver that, say, wants to switch
> the
> hardware from relative to absolute coordinates does not have write
> access to the hardware. The Linux kernel driver DOES, and perhaps
> offers
> repropgrammability through its own API. There has to be an
> opportunity
> for "gluing" to take place.
>
> Thoughts? Places to tell me to go to? All welcome :-)
>
> --
> .:.
> Bryan W. Headley - [EMAIL PROTECTED]
>
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
