Bryan W. Headley writes:
> Egbert Eich wrote:
> > > A lot of error conditions can only be fixed by the administrator.
> > Can you come up with a really good real life example?
> > I suppose 'Battery Low' would be one.
> > That's the easiest one for everyone to grasp. Let's see: problems with > the input device (it didn't accept programming/switch mode commands we > asked for). I'm trying to think what would be a less-than-disasterous > but still inconvenient situation for a video card to report...
>
OK. That makes sense. However if your protocol supports mode setting you can implement this as the success status reported back.
Failures can occur at any time, not just at the time when a status message is being created. That is why, for QoS messages, the driver is the initiator of the message.
(I also agree that status reply messages are good. And would go so far as to suggest that they could be complex, or long messages. E.g., you ask it for its status, and it replies with a message with several Atoms interspersed. Only to differentiate it from an API that only allows the return of an int, or something...)
Depending on the contract of the driver, QoS messages can be sent very irregularly (once every unexplained failure, aka, once every battery failure) or perhaps once every "heartbeat". That depends on what the driver writer thinks is desirable.
--
____ .:. ____
Bryan W. Headley - [EMAIL PROTECTED]
_______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
