Owen Taylor writes: > On Wed, 2003-06-25 at 04:13, Egbert Eich wrote: > > An interesting question appeared on bugzilla (ID #412). > > > > According to the man page of XListInputDevices() the string > > returned in the name field of the XDeviceInfo struct is > > supposed to be one listed in XI.h. > > In reality it is a name specified by the driver. The same is > > true for the type (which according to the XInput Proto specs > > is supposed to be an atom for one of the predefiend device > > types) which however is assigned an Atom according to the > > driver-specified type. > > Returning a device type both as an atom and as a string doesn't > > seem to make sense. I would assume that type should be a predefined > > 'type' to allow an application to identify what kind of devices > > exist while 'name' should identify the type and model of the > > device uniquly and should therefore be a string choosen by the > > driver. > > I assum that this was the intention. Looking at the code in > > common/xf86Xinput.c: > > > > local->atom = MakeAtom(local->name, > > strlen(local->name), > > TRUE); > > AssignTypeAndName (dev, local->atom, local->name); > > > > It should however have been: > > > > local->atom = MakeAtom(local->type_name, > > strlen(local->name), > > TRUE); > > AssignTypeAndName (dev, local->atom, local->name); > > > > As type_name is set to one of the predefined device type names in > > most input drivers. Some drivers set it to local->name which I believe > > is wrong. > > > > Any opinions? > > I would agree with this analysis. If you look at the protocol and > library specifications, they clearly indicate that the strings > in XI.h are to be interned as atoms and compared with the > type field.
Yes. > > The protocol spec has some unclear verbiage about the name > that was probably missinterpreted by the person who wrote the > man page. The library spec doesn't define the 'name' at all. The protocol spec says: "The *name* field contains a pointer to a null-terminated string that corresponds to one of the defined device types." > > Unfortunately, the type names defined in XI.h aren't really > useful because they don't contain the values you need ... > for Wacom tablets, for example, you want to be able to > distinguish the tip and eraser ends of the stylus. (They > appear as different devices in XFree86.) It's not clear to > me whether passing some other atom in the type > field is legal without a protocol spec revision. I don't think so. When XInput was designed the view of such devices was very simplistic. Also the tablet was viewed as the device, not the stylus as one can see by the type "TABLET". However in reality the tablet itself seems to be rather uninteresting - it is as if one would register his mousepad instead of his mouse ;-) However I assume that this list can be extended as it clearly says: "The following names have been defined to date" I agree that this list should probably be extend by defining new types and creating a registry for these. I don't know if a header file is an ideal registry for new types. If you look at Xserver/Xi/extinit.c the code even makes atoms for all these predefined types. I doubt that this is necessary. > > Currently GTK+ determines the type of the device by string > comparison of the name field and hopes people gives devices > conventional names. If the type enumeration was extended, > we could switch to that, but in any case, as long as the > name field is left as it currently, changing the ->type > field won't hurt GTK+. > Currently the device name - not type_name - is used (erronously) for device type. The name field alrady returns a product name instead of a generic device type. Appearantly most software can deal with this well although it violates the specs. If we let the type field return a well defined type (from a type registry) and continue to return a product name in the 'name' field I don't expect any problems although this slightly violates the specs. To do it right we'd have to bump the version number - however we may have to do anyway if we want to address the other outstanding problems with the Xinput extension. Maybe we should start putting together a list of things that we want to see changed in the Xinput extension. I'm not an expert on Xinput form what I have picked along the way: - people would like to be able to identify a device uniquely by an ID (serial number or similar). This could be coded into the 'name' field - which seems to be rather clumbsy. Mayby a new request should be added to query this. - Device hot plugging. We may need an event to notify clients of device addition and removal. - The limitation of 128 unique device IDs appears to be a problem. Maybe this is the time to table all issues we can come up with so we can find solutions. In the meantime I will modify the input drivers to return the id's predefined types in the type field and the product names in the 'name' field. Egbert. _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
