Claus Matthiesen writes:
> > Let's just forget about expanding the _XDeviceInfo struct for a minute
> and just concentrate on the ->type field. Because as regards legacy
> software: Does anybody use the ->type field? I don't want to change the
> ->name, that's fine as it is and that's what most people use now as I
> understand it. It's the ->type field that bugs me because the
> documentation actually says it should return the information I want - it
> just doesn't.
I just seem to remeber that the type field is used in the wrong way by the driver. Some seem to make their own atoms instead of using the predefined ones.
> > Actually, we don't need to re-open the driver as such. If you plug the
> tablet in again, can't we just pretend it's a brand new tablet and that
> the old one just died and went away?
If we don't look for the tablet but for the pens we may even be able to reidentify the pens by their IDs. Not all tablets support pen IDs but some seem to do.
> > > At which point, you might as go the extra steps that MY private API has, > > which allows the client to change ANY parameter of the device driver > > that could be specified in the XF86Config file, while the driver is > > running...
> > ...which is a good thing. We should just make a unified API for it.
The problem is that there is no decend way to communicate this information to the server yet.
Heh. In my spare time, I'll put something together. But things of value that I'm looking at,
1) A layer that can configure/inspect the driver (e.g., it handles everything in the XF86Config file, bidirectionally). Which fits right into making that puppy modular/enterprise controllable.
2) a QoS layer, that the driver can use to initiate it's own messages to unknown listeners.
3) An external event interface. Basically your hotplug events, although I'd like to extend that to supporting a conversation like, "well, a tablet's now plugged in; you have no tablet drivers loaded now. The tablet's identified by 'blahblahblah'. Figure out which driver that corresponds to, load yourself with default settings"
4) Then, some level of user-customizable API. E.g., all parameters have names that are converted to Atoms, whose values are type-safely converted back and forth. Gad, it sounds like SOAP / XML/RPC! Maybe it is...
-- ____ .:. ____ Bryan W. Headley - [EMAIL PROTECTED]
_______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
