Andreas Beck wrote:
> 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.
right, it will not be used to get the system working. However it is nice
to be able for clients to query what sort of configuration the system currently
has. See xdpyinfo, xinput, and friends.
> 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.
now consider the user wanting to configure (graphically, with all kinds of other
jazz...) his windowing system, i.e. setting up the kind of event types he wants
to use, i.e. the sensitivity of the stylus, etc.
Do you really expect him to mess with the low level stuff like 'origin' etc. ?
I'd rather try to insulate that stuff from the user, letting him deal with
more descriptive information. And as you say, there is (or ought to be) an
unambiguous mapping between the two, so the system can still use the 'origin'
and co., while presenting the metainfo to the user.
> 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.
right, and the problem I pointed out is still there: a potential buffer overflow
for long 'contents'.
> That's the fun thing about an event oriented protocol.
indeed. But I doubt that for this kind of information we really want an asynchronous
API. These metadata are usually queried once (either at startup or whenever a new
device
is plugged in), and then dealt with by the high level layers.
> > 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.
The same would be true for my proposed dictionary. It would be associated with
a device, so memory management shouldn't be an issue.
> This however means, that there must be no externally referenced data that
> would need freeing or similar.
understood.
> 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.
ok, this simply means that certain kind of information can't be dealt with
in an event driven way. That's fine.
> > 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.
<rant>
I sometimes really wonder why people still consider C such a wonderful tool.
You'd never have such trouble in C++.
</rant>
> Having no external data at all and the event length known, this is simple.
well, everything is simple if you constrain the problem domain you address :)
> 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
uh, let me have another take at that:
if you start with a 'nice and simple' model which doesn't scale (you call it
'making a few people happy', I call it flexibility), why do you blame these
'few people' (or did I read something into these lines ? :)
Seriously, I don't see a big deal in adding a simple function to query
(synchronously, much like the giiQueryDeviceInfoByNumber() function you
pointed out) that returns heap allocated data (with clear ownership semantics !)
with additional information that can't be obtained with events.
<rant>
Alternatively, an event might be more OOish by containing a 'destructor',
i.e. a cleanup handler that is called to clean it up. That is poor mans
polymorphism at work, i.e. a way to assign specific behavior to specific event
types.
</rant>
To sum it all up:
I acknowledge that not many people currently see the need for a more extensive
set of metadata. I also agree that it is difficult to fit such a thing into
the event driven backbone of GII. My proposal is to add a *synchronous*
interface to GII to let users query device information. That would (IMO) even
render the current command events obsolete.
Regards,
Stefan
