[Openicc] Drop size calibration

[Hal V. Engel]

On Monday 04 February 2008 12:17:00 edmund ronald wrote:
> I was thinking of a taget device which is a spectrophotometer that
> measures media - which is a very static external application that
> simply sends back a CGATS Ascii file, as you know better than me. This
> would be sufficient for the purposes of the print calibration crowd. I
> would agree that creen calibration etc may be a more painful issue as
> it interacts with peripherals more closely embedded in the host system
> ....
>
> Edmund

Edmund,

Even measuring print targets requires some user interaction.  For example to 
tell users which strip to swipe next and give them feed back if there is an 
error and so on.

For the virtualized device driver that you were talking about I was thinking 
that this would be exposed at the level of the device vendors API and that 
software could interact with it in the same way it would if it was running on 
a platform where the vendors drivers and interface library is supported 
natively.  This would make it transparent to the client software if is was 
using the virtualized driver or the native driver since the API would look 
the same in either case.  Then the "transport protocol" between the 
application and the actual device library would either be a direct API call 
to the library (IE. data passed on the stack) or a call to an interface layer 
that connected to the virtualized device via TCP/IP that passed the call and 
data to the virtualized device driver and then passed the results back to the 
original caller.  The application side interface layer would be fairly simple 
(since all it does is encapsolate the API and passed data between the real 
driver and the application) and could be made available as source code so 
that it could be built for any platform that supported TCP/IP (which is 
everything now days).

Again I am not saying that this couldn't be made to work but rather that this 
is a lot of added technical complexity (IE. creating and setting up the 
virtualized driver) that is being used to solve what is clearly not a 
technical problem. 

Hal

>
> On Feb 4, 2008 8:35 PM, Hal V. Engel <hvengel at astound.net> wrote:
> > Your virtual appliance idea is one possible approach that might work with
> > this class of devices (but probably not all types of devices).  But there
> > are likely to be significant issues implementing the virtual device.  
> > Looking at the existing virtualization tools like VMWare and QEMU
> > interfacing this virtual device to software running in the host
> > environment is likely non-trivial.  Part of the difficultly is that these
> > virtual machines are not designed to expose virtualized devices to the
> > host system.