Hi folks, let me play Advocatus Diaboli for a moment here:
> I believe the strings given by the evdev driver are pulled out of the device
> firmware, at least for USB. Also, just because the evdev (==USB right now
> on Linux) API has a driver name, a device name, and a vendor name does not
> mean all LibGII input targets will have these three values. They may have
> more, in fact, like, for example, a locale code. By using/parsing a string,
> we have a solution that will always extract the correct field, and when joe
> user goes to MediaPlay and buys his "PowerSandle" in May of 2006, the crusty
> old installed-from-CD libc7 RedHat version of LibGII he has on his computer
> will allow an app to say:
>
> "Found Input Device: PowerSandle v3.2, (Logitech) 6 axis, 0 buttons"
> even though the PowerSandle didn't exist when it was compiled.
Yeah, but what good is that information ? Other than helping the user to
identify which device is which, I don't see why a highlevel application
should be concerned about the version and other details of the underlying
hardware. This stuff is usually not needed to make an application behave
like it should - it's there for debugging purposes.
All I need to configure my work environment is a list of devices I have,
which is unambigous. As one rarely has multiple identical devices which only
differ by say the version (I think it's more likely to have multiple exactly
identical devices than that, and then you are up to trying it out anyway),
I'd say a simple device string, eventually with some kind of BusID or
something should do.
Having said that, I'd like to point out, that it is easily possible _within_
the existing API to have events that are private to specific drivers or to
add generic additional events.
If you really really still want that exact version and whatnot reporting, we
can easily add a simple command event like say
GII_CMDCODE_GETDEVENVIRONEMNT
typedef struct {
char name[75];
char content[75];
} gii_cmddata_getdevenv;
Note that device information is pulled in excatly the same way already.
That's the fun thing about an event oriented protocol.
> The main problem though, is that there is likely a reason why fixed size
> was used.
Yes. It is an event protocol. The whole point about it, is that you can
ignore events you don't understand or are not interested in.
This however means, that there must be no externally referenced data that
would need freeing or similar.
Moreover the event protocol is designed to be pipeable within an
architecture, across process and context (kernel/user space) boundaries.
Note that EvStack had /dev/event devices which talked LibGII events.
> We need to carefully review the implications of adding a variably sized
> event;
It is possible, as long as you stay within the limits. An event must always
fit into a gii_event and it must not contain external data.
> at minimum I anticipate we will need to malloc the event and the string in
> the same inscestuous structure such that nothing leaks if you just free
> the event.
Events are not objects like in an OOP language. The point is, that if you
want to be able to ignore unknown stuff, you need a generic way to free it.
Having no external data at all and the event length known, this is simple.
Other methods are possible, but if you want to know what comes out, when you
start with that nice and simple approach and later add lots of cruft to it
to make a few people happy, please have a look at the specs of DICOM
(our interpretation of that acronym is "Das Ist'n Chaos ! Oh Mann !" which
translates to something like "That's a Mess ! Oh Boy !"), a medical imaging
format. I have made a reader for it, which works great, but is a horrible
hack and uses a heuristic approach to get all that strange possible formats
and exceptions in an acceptable number of code lines.
CU, Andy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
