Depend on ufodecode 0.2

[Matthias Vogelgesang]

Two reasons:

• ufodecode 0.2 broke the API
• ufodecode 0.2 provides the meta data mechanism that pushes status information for each frame

What we need for libuca from pcilib is:

• a similar mechanism to get the meta data for each (though this should be opt-in, I guess?)
• enums that explain error codes and states
• as a bonus point there would be either an array that maps enum values to

  struct { 
     const char *name;
     const char *description; 
  }
  

• … or a table that contains all of that:

  struct {
     unsigned int value;
     const char *name;
     const char *description; 
  }
  

[Suren A. Chilingaryan]

• I pass through the meta data from ufodecode. You get pcilib_event_info_t as parameter into the callback function. In case of ipecamera it is ipecamera_event_info_t. I just added property "meta" which will be filled by ufodecode. If you are using get_next_event call instead, the pcilib will return either pcilib_event_info_t or ipecamera_event_info_t depending on size of info buffer you will provide.
• Why opt-in? You'll decoding it anyway. So, if decoding is enabled, I'll pass this metadata over.
• About errors: as you proposed I just returning errno codes. Currently, I don't have any string information associated with errors. So, just strerror will provide all information I know about the problem.
• Sure, I can start handling errors differently providing the same strings I'm currently printing out. But this is quite major change through the all the code. I'd not start it without major rewrite required anyway.

[Matthias Vogelgesang]

Replying to csa:

• About errors: as you proposed I just returning errno codes. Currently, I don't have any string information associated with errors. So, just strerror will provide all information I know about the problem.

It's not about errors stemming from pcilib itself (the error codes are just fine) but from the camera itself. I mean, if you want to abstract from hardware details via "virtual" registers you must do something similar for errors, right?

[Suren A. Chilingaryan]

Do you mean associating values of Michele's status registers with error messages?

[Matthias Vogelgesang]

That is correct. At least enums that list all possible statuses (from, the data sheet that Michele sent us) would be helpful if you don't want to return messages.

[Suren A. Chilingaryan]

OK. It is clear now. I'll think.

[Suren A. Chilingaryan]

Name is misleading, replaced by #104