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.
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.
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.
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+.
Regards
Owen
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
