----- Original Message ----- From: "Bryan W. Headley" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, August 26, 2003 9:43 PM Subject: Re: XInput: The device type in XListInputDevices comes up again...
<Cut a bit of code> > > > The problem is, there's a type field and a name field. They're not > > > populated consistently by all drivers, and the fields are not sufficient > > > to accurately describe the device, anyway. > > > > That is correct. However Claus was talking about the future - once > > that is fixed. Appearantly toolkits like gnome already do make use > > of the name field. > > Sure, albeit dangerously. They had best not be making decisions based on > what's returned in the string... Exactly. Sort of guessing on the basis of a string which might contain this or that isn't good enough for industrial strength software which we all agree should be able to run under Linux/XFree. But unless I am much mistaken, there is *no other* way of finding out which kind of device one's got ones hands on - please correct me if I'm wrong, because that's what I need... > > > you make an Atom, call it XI_STYLUS, etc., and mess you up, because > > > you'd hardly be expected to know that a XI_STYLUS is related to a tablet But do you really need to know that? Isn't it enough to know it's a stylus? If you've got two tablets (which after all must be a bit rare) do you care, either from the applications or the users point of view, which tablet is used with which stylus? (I am here ignoring the fact that the stylae must physically work with the tablets of course) As far as I understand it (without being an expert on tablets) the fact that there's a tablet is rather uninteresting. > > > (that's sort of localized knowledge to the given device being supported). > > > > The term 'tablet' is inconclusive. XI_TABLET should not be used for such > > tablets. > > I can argue both for and against that statement. Don't forget, the > application using the API possibly will want to indicate the pen device > #1, #2 and mouse device #3 are all related to a tablet, in the spirit of > user-friendliness. ...and if that's really useful knowledge, what you're saying is that we need some sort of grouping of devices. Well, I can go along with that... > The tablet itself is not really the device as far as XI is > > concerned. It does not provide coordinates/keys/buttons itself. > > Yes it is but no it isn't. Remember, there is a single cable running > from the tablet to the USB port. Which means, if it's hotplug disabled, > somebody has to understand that all these devices should be disabled... But if stylus, cursor and eraser are all registered as unique devices, won't that just mean that for every registered device we get a message that it's been unplugged? It can't be a problem to disable all the devices which are plugged into the tablet within X itself when the tablet is unplugged or switched off and then X just needs to tell me as an application programmer that each of these devices - the stylus, eraser, etc. - have been disabled... > > > What I'd like, but haven't started an in-depth search for in the API: > > > given a deviceInfo struct, I'd like to learn the device driver name > > > associated with the device. > > > > The device driver is completely irrelevant to the application. > > Why should the application know that? The application may want > > to know a vendor string and an ID to know more about the properties > > of an individual device (some pens supply pressure or angular data > > some don't). > > Most do not. Mine does, because it's the client side of that > client/driver API I mentioned: it has to know which drivers support my > extended API. But I don't expect to find that kind of info in the > deviceInfo struct... Ideally, shouldn't the _XDeviceInfo struct contain some sort of information about how to decode the information in the events one receives from the device? It's certainly not very elegant if it's necessary to have the program explicitly know which tablet the driver is running. The whole point of a driver is to have a unified interface. If there's something this interface can't express then it's a problem with the interface and it must be changed or expanded. > > These would be properties. Properties can be accumulated, types are > > exclusive. I don't know if we can manage to characterize all device > > properties completely and if this is desirable. In many cases we may > > just be able to supply coordinates and the application needs to be > > configured to know what to do with these. > > A heirarchical system is the way to go. Well - isn't that an overkill? So far the only thing that's come up as a problem is a tablet and that has only one level of hierachy which is even a bit contorted since the highest level in the hierachy - the tablet - doesn't produce events while the lower level - stylus, eraser, etc. - does. Summation: a) Can't every device attached to a tablet just become an independent device in X, so that one can ask for an XI_CURSOR, XI_STYLUS or XI_ERASER? We might expand the _XDeviceInfo struct to contain information about grouping if that's desired. This could be implemented quite quickly... b) As far as I understand there's no way of knowing in X now if a device has become disabled or unplugged. There should be, of course. Would it be sufficient one just received a "unplugged"-event from the device? This could also be implemented relatively quickly, I think... c) Should the device information somehow be expanded to help the programmer understand more advanced input from the device so that one is not bound to the rather static way the current extended-event struct is made? d) Are there any other "problematic" devices in terms of the current device structure in X than the tablet that anyone knows of? Let me finish by saying that even though I have never had my hands deep in the code of X, of course I'd be happy to help out - if doing a little coding in X makes my port of the toolkit go smoother it's definetely worth the effort. All I need to have is a consensus on what we want. /Claus _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
