Re: XInput: The device type in XListInputDevices comes up again...
On Thu, 2003-08-28 at 17:59, Egbert Eich wrote: Claus Matthiesen writes: 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... Unfortunately no. What we probably need is a Registry for known devices. However the naming sceme needs to be generic enough to also hold enough information so that if a device is not known to an application that the application can do something useful with it Actually, I'm really getting into the idea that the device can sort of tell the application how to interpret its data. I'll elaborate later in the mail... 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. You may want to 'bind' one tablet to one application and the other one to another appication. I don't know if this would be any useful. You could use the same stylus on both tablets (if both tablets can use this styles) and then it would appear as a different device. The tablet itself however doesn't have to appear at all - as you said. As I was trying to find some clever way of making a general structure without using a hierachy, I realized that that probably is the easiest, most future-secure way of doing it. Alright, you convinced me. (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... Or a hirachy. Input devices are a rather wide area. I have difficulties to overlook what all may be required, but when we extend the XInput extension we must be careful not to impose limits like the old one did. Yes, yes! You already swayed me! :-) 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... Yes. 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. Yes. But with the wide range of input devices how unified can this be? You can always treat something generically - but you will be missing some of the device dependend features. This is semi-correct. Which means that it's correct unless you're very careful when you design it. But we're being careful, aren't we? Again, I'll elaborate later on the flexible API I'm thinking of later... 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. It may or may not be. Input devices are not tablets only. Yes, yes! A hierachy! OK! :-) 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
New device handling in X (was: XInput: The device type inXListInputDevices comes up again...)
This is a summation of the discussion between the est. Bryan W. Headley, the est. Egbert Eich and myself so far, along with a few new ideas... OK. Most people seem to think we need a new way to do device handling of what is currently called extended devices in X. I, as an applications programmer, find that it is far too restrictive and very importantly that the device drivers written for it do not sufficiently conform to the documentation, and the device programmers find that it cannot express all the aspects of a modern Human Input Device (or HID). There are two choices: Either to fix the old broken API or to make something new and phase the old API out. In favor of fixing the old API is the fact that making a new one would mean going over every driver to make them conform to the new API. This is a large task. Besides, people know the old API. In favor of making a new API and phasing the old one out are: a) We can do it much better without being inhibited by any choices that were made in the old one. b) Because it's a new API it's easier to enforce the standard rigidly so we don't get all that I'm putting something different in the -type and -name field than you-nightmare all over again. c) People might know the old API but it's not exactly loved... d) If we expand the old API, we probably still need to go over most drivers. As you might gather, I'm all for making a new API. --- If the situation looks like this: Applications -- XInput API -- Device drivers -- Kernel then there's no denying that my experience lies mostly in the two upper parts. I also understand that Bryan is mostly down in the two lower parts, occasionally sticking his head all the way up to Applications level (correct me if I'm wrong, that's just the impression I got from the correspondence). Since it's the primarily the API that's ineffective, I suggest starting from there - that's also what we all know something about. Summing up on the discussion so far, we want an API with: a) Hierarchial ordering of devices. b) Hot-pluggability. c) An extremely flexible interface for letting the application know what the device is telling us. d) The possibility to have communication back and forth between device(driver) and application. I propose that we simply start by defining the new API as a header file (or set of header files). The first version might not look anything like the finished result but we'll have something constructive to work from and a common reference. I would be happy to make a suggestion which I will hasten to say would *not* be my idea of how it should be but rather some loose sketches on what it might be which we can then add to and change as befits us. How does this sound? --- And now for the rambling brain-storm part of the mail: As regards the flexible interface, I was thinking... Practically all devices actually send rather kinds similar information. I'm not sure what a dataglove sends but a mouse basically sends a point and so do tablets as far as I know - of course they're respectively relative and absolute coordinates, but still. Joysticks actually send a 2d-vector (which is [0, 0] when it's not touched), spaceballs send a 3d-vector... All of them neat physical concepts. Was it possible that upon opening the device, you could be told: When I'm sending you an event, it's going to be so-and-so long. There will be x longs (or reals or whatever) of information, of which the first two will be an absolute position, the next two will be button states, etc. etc. A dataglove might send 20 or something 3d-points with every event, one for each point on the glove. I know this is crude but it is just to let you understand the general idea. After all, the physical devices are real-world objects; what they put into the computer is real-world information. If you can interpret 2d- and 3d points and vectors and radians, what other kinds of measurement are there, physically speaking? If we could only structure the information in some way so that it's easier for the application to understand... The hierarchial structure might, in fact, help. Consider the dataglove again. We could register the glove with each finder as a subdevice which each measurement point along the finger as a subdevice again. Suddenly, the structure of the information makes it much easier for the application to understand the data... Does this make any sense? Looking forward to your input, /Claus ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
- 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
Re: XInput: The device type in XListInputDevices comes up again...
Weee! Device interface designing is fun! As a side note - isn't it rater a failure of the extended input thingy in X when neither the application programmer nor the device driver programmer think it's good enough? On Wed, 2003-08-27 at 17:03, Bryan W. Headley wrote: Claus Matthiesen wrote: - 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... Well, if you are doing a switch/case on the Atom, this infers very strongly that you know upfront what every Atom could be for your decision tree. But if you don't care, you convert the Atom to a char*, display it, and maybe the string's meaning is implicit to the viewer... In detail, what I want to do is this: I'm programming this toolkit in C++. I've created a nifty little classes for the kinds of devices I pretend to know anything about - which for now are keyboards, mice and tablets, with spaceballs and datagloves as a likely addition. When I go through the device list I get from XListInputDevices, I want to map one of these classes to all the devices I know how to handle, ignore the others and so get a list of objects representing every device I know how to deal with. And that's not easy when there's no safe way to classify each device... I'm almost embarrased to say so, but under Windows XP and its new RawInput library, everything works fine... :-) What will drive you insane is that tablet device driver X likes names like 'Stylus', and Y likes to put the name of a manufacturer, but Z prefers putting the names of fruits (and of course, I prefer putting the driver's identifier, so it matches the XF86Config file). You'll go insane keeping track of my weirdness versus the fruit guy's... Exactly. But that's not a reason to give up, that's just a reason to make a standard and make Mr. X, Y and Ms. Z follow it. But I see your point - the way it is now, there's no way to do 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. Yes, I do. In a hotplug situation, where the tablet is unplugged while the server is running, I'm going to be told by the kernel that tablet-x is gone. I have to understand that this means either disabling or passivating the device drivers for stylus-y, cursor-z, and eraser-a. Hmmm... I think the problem is this: I, as an application programmer, do not need to know that all these tablet devices are tied to one tablet; you, as a device driver programmer do need to know. I am aware that behind the X extension layer, it's very much necessary to know that these devices are on a tablet. Otherwise it would be impossible to let me know when the devices tied to the tablet have become unplugged. Actually, it's worse than that: the kernel neither knows nor cares that the device mapped to pci:00/:00:1f.4/usb2/2-1/2-1:0 was a tablet of type XI_TABLET. If I'm lucky, it might think to pass the USB vendorID and productID which would tell me that it's an Aiptek 8000U (but then I have to establish the relationship of that with XI_TABLET with the name of... what? (I prefer pci:00/:00:1f.4/usb2/2-1/2-1:0) Associated with file descriptor 'x'... Who is being used in a select() call by several X input drivers that I now need to passivate or perhaps remove entirely from memory. And just because I'm into fun, let me advise you that /dev/input/event2, which might be the device
Re: XInput: The device type in XListInputDevices comes up again...
On Wed, 2003-08-27 at 19:52, Bryan W. Headley wrote: Claus Matthiesen wrote: Weee! Device interface designing is fun! As a side note - isn't it rater a failure of the extended input thingy in X when neither the application programmer nor the device driver programmer think it's good enough? La la la la. I can't read you :-) Ahem... eh... I mean of course, *at the time* it might have appeared the way to go... :-) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
