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
