Bryan W. Headley writes: > Egbert Eich wrote: > > > > > > That just illustrates the problem. Who would think to look at the Misc > > > extension for that? > > > > I do. > > I wouldn't. You could tell me that Misc deals with TrueType fonts and > translucense, and I'd have no reason to disbelieve you, until I looked > at the headers/docs...
Misc and XF86misc are different extensions. > > > The point is: I'd opt a uniform concept to talk to the hw driver > > layer for all devices. There are other devices than just input > > devices. Correnly even the option handling of input drivers is > > different from graphics drivers. If possible these things should > > be made uniform. > > Me, too. > > > So what would you propose? Duplicate this in another extension > > or handling output drivers thu XI? > > Absolutely not. One communications layer; it deals with all device > drivers. This is a fair summary of what I've been talking about all along, > > 1. It deals with all driver configuration/reconfiguration/querying of > configuration. "Configuration" as defined as that specifiable in your > XG86Config file. Also will deal with driver activation/deactivation, in > response to an external Hotplug notification facility. > > 2. Driver state querying/programming. We're talking about the sort of > parameters you currently see in the device-specific Misc extension, the > XI extension, Even bizarro things like asking the current battery power > level can be serviced at this level. > > 3. I still want drivers to be able to initiate their own messages, > a) to report error conditions (battery too low; device unavailable) If this gets passed to the X client it would be an event. > b) send requests to external agents who can do things the X driver > cannot. Example: Under Linux HID, you cannot program the HID > device from its client API (e.g., no ioctls to switch from > relative to absolute coordiantes) But it may be known that > the kernel driver DOES support mode switching through other > means (the ubiquitous procfs/sysfs) This is ugly. It could be done but then we'd have a linux only driver. If the HID interface would offer such things one could design a generic system interface with a OS dependent and an OS independent part. A lot of what you are describing is what I have in mind for my new xf86misc extension. Maybe it should be given a different name. However I first want to have code and then I can think about a name. Egbert. _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
