Bryan W. Headley writes: > Egbert Eich wrote: > > Bryan W. Headley writes: > > As opposed to writing it to a log file. However keep in mind that what > the X client opts to do with any such message(s) is up to that > installation, including logging it to a file. But I'm thinking more > along the lines of a) notifying the user with some dialog, or b) passing > the message to the help desk through unknown mechanisms. (Email! :-)
Sure, the client is free to do whatever it wants. > > > > > > 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. > > What I wanted to get across was the notion that the driver COULD > initiate a conversation with a client of a very singular nature. Putting > that into the API resolves any issues from people subverting other calls > for their purposes. > > Regards "generic system interface"... we presently have several drivers > that support different IO subsystems, and as a consequence are repeating > code. Layers that I see are, > > o Datastream retrieval. E.g., is it RS-232, USB, Linux Input, Firewire? > Such a layer needs to know the OS device entry, perhaps information on > baud rate, etc. Highly reusable; we're talking about one set of binary > per input type; one-to-many state objects (one per open connection) Yes. > > o Packet building. This would be input device/interface type specific. > It would know that a packet of incoming data is 'x' bytes in length; it > might understand that bit 4 is always set for synchronization purposes. > It composes the hardware's packet into a generic packet, understood by, > > o Device Driver. The layer that understands that it's receiving input > from a Wacom tablet; it's able to convert incoming packets into > PostMotion events. Specific to the generic hardware product, but only > requires a new packet builder to support a new input interface. > I don't know if it is worth the trouble to separate the two latter ones. If I look at mice (which I've worked for recently) I see an opportunity to put in a generic post processing layer between the bare axis and button detection and the PostMotion/Button() call. Egbert. _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
