Home > Archive > Visual Basic Syntax > April 2005 > IStiDeviceControl::GetMyDevicePortName
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
IStiDeviceControl::GetMyDevicePortName
|
|
|
| Does anyone know how to make the above call from VB6 (under W98)?
Long story, but I'm trying to access kernel-mode drivers for still
image devices (a USB scanner) so I can talk to the device directly. (I
*don't* want to use TWAIN!)
According to the MS docs I must first CreateFile using the above
device's port name as a parameter. Fine and dandy, but...
One of the (many) questions and what I'm not entirely clear on is
this: The IStiDeviceControl::GetMyDevicePortName returns a string with
the device's port name, but how do I select which device I want to
talk to!?
But, let's burn that bridge when we get to it. First things first:
how do I make the above call?
Thanks!
Don.
Danny
(You guessed it! Remove NOSPAMFOR before emailing.)
| |
| Mark Yudkin 2005-03-28, 8:58 am |
| Given that you're using VB6, writing a user mode device driver to talk to a
kernel driver will probably be a non-trivial exercise. Unless you've built
your own scanner, I also have difficulty seeing the point of it. And if you
did, you should probably be coding in C++.
The concrete answer to your question is that
IStiDeviceControl::GetMyDevicePortName assumes that you already have
obntained the device that you wish to control from IStiUSD::Initialize.
IStiUSD is an interface that your mini-driver implements. Hence the answer
is that your driver must know what device it supports in order for it to
support that device. You set up "the which device does my driver drive"
during the installation of your device driver, and the system will call you
when an application tries to use your device driver to drive the device.
Back to my initial comment - if all you're trying do do is control still
image capture from your scanner, why don't you use WIA - which is amenable
to VB6 - rather than STI?
"Danny" <NOSPAMFORdaniel_ahorn@yahoo.com> wrote in message
news:0gce41pbggl3b6d5a97fcs0t0nfi89ubne@
4ax.com...
> Does anyone know how to make the above call from VB6 (under W98)?
>
> Long story, but I'm trying to access kernel-mode drivers for still
> image devices (a USB scanner) so I can talk to the device directly. (I
> *don't* want to use TWAIN!)
>
> According to the MS docs I must first CreateFile using the above
> device's port name as a parameter. Fine and dandy, but...
>
> One of the (many) questions and what I'm not entirely clear on is
> this: The IStiDeviceControl::GetMyDevicePortName returns a string with
> the device's port name, but how do I select which device I want to
> talk to!?
>
> But, let's burn that bridge when we get to it. First things first:
> how do I make the above call?
>
> Thanks!
>
> Don.
>
> Danny
>
> (You guessed it! Remove NOSPAMFOR before emailing.)
| |
|
| No, it's a commercial scanner, but I'm getting some strange results
(real pedantic stuff, though, after examining 16-bit histograms). I
suspect the culprit is TWAIN so to confirm that I would like to get
unadulterated, raw, pure data from the scanner.
But more importantly, the low level commands have abilities (not
capabilities) which TWAIN "hides". By going below TWAIN I should be
able to make use of them too.
Regarding WIA, if I read the documentation correctly WIA doesn't apply
to W98, so I appear to be stuck with STI.
So, do you happen to have some examples of how to make IStiUSD::,
IStiDeviceControl:: calls in VB6? Specifically, which declares do I
need?
At the root of this is a more basic question I have been wrestling
with for some time. I'd like to work at a level above the hardware
(and leave talking to the USB controller chip to the OS) but below any
drivers (which entangle me in the many abstraction layers of the USB
paradigm). I'd like to work at an intermediate level where bytes are
just bytes...
Danny
(You guessed it! Remove NOSPAMFOR before emailing.)
Date: Mon, 28 Mar 2005 09:52:40 +0200
Name: "Mark Yudkin" <myudkinATcompuserveDOTcom@boing.org>
>Given that you're using VB6, writing a user mode device driver to talk to a
>kernel driver will probably be a non-trivial exercise. Unless you've built
>your own scanner, I also have difficulty seeing the point of it. And if you
>did, you should probably be coding in C++.
>
>The concrete answer to your question is that
>IStiDeviceControl::GetMyDevicePortName assumes that you already have
>obntained the device that you wish to control from IStiUSD::Initialize.
>IStiUSD is an interface that your mini-driver implements. Hence the answer
>is that your driver must know what device it supports in order for it to
>support that device. You set up "the which device does my driver drive"
>during the installation of your device driver, and the system will call you
>when an application tries to use your device driver to drive the device.
>
>Back to my initial comment - if all you're trying do do is control still
>image capture from your scanner, why don't you use WIA - which is amenable
>to VB6 - rather than STI?
>
>"Danny" <NOSPAMFORdaniel_ahorn@yahoo.com> wrote in message
> news:0gce41pbggl3b6d5a97fcs0t0nfi89ubne@
4ax.com...
>
Danny
(You guessed it! Remove NOSPAMFOR before emailing.)
| |
| Ron Weiner 2005-03-28, 9:00 pm |
| Mark
Wonder if I could jump in here. I am also looking to interface an app I am
writing with a USB Bar Code scanner. Right now I am using the scanner in
"keyboard wedge mode". The problem with this is making sure I have my app
in a position to actually see the keystrokes when they come down the pipe.
If the focus on my main form is on it WebBrowser control the form is totally
BLIND to the keystrokes (even though I have KeyPreview set to True).
Sooo.... I am thinking that if I can communicate directly with the darn
thing via the USB bus I can (hopefully) have my code shovel bytes into a
buffer that I could poll from time to time to get the scanned codes. Would
be even better if I could raise an event from my shoveling code when the bar
code scanner sends the "STOP" code, so my main processing loop can do its
thing, and clear out the buffer.
Can this be done using VB6 to make various and sundry API calls? If so can
you point me into the right direction.
Thanks
Ron W
"Mark Yudkin" <myudkinATcompuserveDOTcom@boing.org> wrote in message
news:uN4u7r2MFHA.2656@TK2MSFTNGP10.phx.gbl...
> Given that you're using VB6, writing a user mode device driver to talk to
a
> kernel driver will probably be a non-trivial exercise. Unless you've built
> your own scanner, I also have difficulty seeing the point of it. And if
you
> did, you should probably be coding in C++.
>
> The concrete answer to your question is that
> IStiDeviceControl::GetMyDevicePortName assumes that you already have
> obntained the device that you wish to control from IStiUSD::Initialize.
> IStiUSD is an interface that your mini-driver implements. Hence the answer
> is that your driver must know what device it supports in order for it to
> support that device. You set up "the which device does my driver drive"
> during the installation of your device driver, and the system will call
you
> when an application tries to use your device driver to drive the device.
>
> Back to my initial comment - if all you're trying do do is control still
> image capture from your scanner, why don't you use WIA - which is amenable
> to VB6 - rather than STI?
>
> "Danny" <NOSPAMFORdaniel_ahorn@yahoo.com> wrote in message
> news:0gce41pbggl3b6d5a97fcs0t0nfi89ubne@
4ax.com...
>
>
| |
| J French 2005-03-29, 9:01 am |
| On Mon, 28 Mar 2005 18:28:36 -0500, "Ron Weiner"
<weinNoSpam1@mindspring.com> wrote:
>Mark
>
>Wonder if I could jump in here. I am also looking to interface an app I am
>writing with a USB Bar Code scanner. Right now I am using the scanner in
>"keyboard wedge mode". The problem with this is making sure I have my app
>in a position to actually see the keystrokes when they come down the pipe.
>If the focus on my main form is on it WebBrowser control the form is totally
>BLIND to the keystrokes (even though I have KeyPreview set to True).
>
>Sooo.... I am thinking that if I can communicate directly with the darn
>thing via the USB bus I can (hopefully) have my code shovel bytes into a
>buffer that I could poll from time to time to get the scanned codes. Would
>be even better if I could raise an event from my shoveling code when the bar
>code scanner sends the "STOP" code, so my main processing loop can do its
>thing, and clear out the buffer.
>
>Can this be done using VB6 to make various and sundry API calls? If so can
>you point me into the right direction.
I think the idea of trying to (effectively) write a USB driver in VB
is pretty ambitious.
The simple solution is for you to get a scanner that pretends to be a
RS232 rather than a keyboard wedge.
One rather gash solution that occurs to me is to use RegisterHotKey
for all possible characters - very gash ..
I would not recommend a System wide hook, I've been there using Delphi
and it is slightly painful
- but mostly those things are supposed to blow up when certain
software is installed.
| |
| Ron Weiner 2005-03-29, 9:01 am |
| There ya go! Why didn't I think of that? I am already hooking the
WebBrowser control to keep the Right Mouse button from firing. So might as
well start trapping the keyboard events too. I will let you know how I make
out.
Ron W
"J French" <erewhon@nowhere.uk> wrote in message
news:42490bb1.165869336@news.btclick.com...
> On Mon, 28 Mar 2005 18:28:36 -0500, "Ron Weiner"
> <weinNoSpam1@mindspring.com> wrote:
>
am[color=darkred]
app[color=darkred]
pipe.[color=darkred]
totally[color=darkred]
Would[color=darkred]
bar[color=darkred]
can[color=darkred]
>
> I think the idea of trying to (effectively) write a USB driver in VB
> is pretty ambitious.
>
> The simple solution is for you to get a scanner that pretends to be a
> RS232 rather than a keyboard wedge.
>
> One rather gash solution that occurs to me is to use RegisterHotKey
> for all possible characters - very gash ..
>
> I would not recommend a System wide hook, I've been there using Delphi
> and it is slightly painful
> - but mostly those things are supposed to blow up when certain
> software is installed.
>
>
| |
|
| Date: Tue, 29 Mar 2005 08:05:13 +0000 (UTC)
Name: erewhon@nowhere.uk (J French)
>
>I think the idea of trying to (effectively) write a USB driver in VB
>is pretty ambitious.
I don't think it's that hard if all we want is just to talk to the USB
device directly. The hard part is interfacing with Windows for all the
(from our view) "bloat" such as PnP support, etc.
Indeed, I'd say that just examining and sending USB packets is
probably considerably simpler than getting mired in the ("infinite")
Windows USB stack sitting on top of it.
To draw a parallel, it's like, circumventing the file system and doing
a raw read/write of disk sectors. In a way, all we want to do is a USB
"raw read/write".
Of course, doing that means giving up a whole bunch of higher
functions but since I, for one, don't need those higher functions,
it's not really a loss. What I gain is a massive reduction in
complexity.
To extend the above example, if you want to write a simple "refresh"
program to read and write all sectors on disk, circumventing the fs
overhead and doing a raw read/write simplifies (and speeds up) things
immensely.
Danny
(You guessed it! Remove NOSPAMFOR before emailing.)
| |
| J French 2005-03-30, 4:03 am |
| On Tue, 29 Mar 2005 21:14:12 +0200, Danny
<NOSPAMFORdaniel_ahorn@yahoo.com> wrote:
<snip>
[color=darkred]
>I don't think it's that hard if all we want is just to talk to the USB
>device directly. The hard part is interfacing with Windows for all the
>(from our view) "bloat" such as PnP support, etc.
>Indeed, I'd say that just examining and sending USB packets is
>probably considerably simpler than getting mired in the ("infinite")
>Windows USB stack sitting on top of it.
>To draw a parallel, it's like, circumventing the file system and doing
>a raw read/write of disk sectors. In a way, all we want to do is a USB
>"raw read/write".
I don't think it is at all like that
- USB is closer to an ISA or SCSI Bus than a block device
>Of course, doing that means giving up a whole bunch of higher
>functions but since I, for one, don't need those higher functions,
>it's not really a loss. What I gain is a massive reduction in
>complexity.
>To extend the above example, if you want to write a simple "refresh"
>program to read and write all sectors on disk, circumventing the fs
>overhead and doing a raw read/write simplifies (and speeds up) things
>immensely.
Well I would use Int 25h and Int 26h for that
- you can still get at them via DeviceIOControl
I might be wrong, but unless you know an awful lot about your USB
device, I think you are in for a hard time.
I get a little hacked off seeing posts where people understand the 'S'
in USB - but do not understand what the 'B' stands for.
Good luck anyway.
| |
|
| Date: Wed, 30 Mar 2005 04:20:45 +0000 (UTC)
Name: erewhon@nowhere.uk (J French)
>
>I don't think it is at all like that
>- USB is closer to an ISA or SCSI Bus than a block device
Yes, of course. I was just referring to the low level aspect i.e. they
are both the underlying layer.
>Well I would use Int 25h and Int 26h for that
That's exactly the problem because there are no equivalent absolute
USB read/write calls that I know of.
>I get a little hacked off seeing posts where people understand the 'S'
>in USB - but do not understand what the 'B' stands for.
Indeed! It is a bus. But by the same token (sic) at the most
elementary level it just shuffles packets back and forth. The problem
is that this layer has been successfully "hidden" by a stack of
abstraction ("obstruction") layers sitting on top of it.
Other buses have similar structures but they're not as "secretive"
about their fundaments as USB is. The challenge is to peel this
"bloat" off and expose these basics which are intrinsically simple.
Or, more accurately, expose how to access those basics using available
tools.
>Good luck anyway.
Thanks! I've been at this - on and off - for months. I started out by
disassembling various libraries. Of course, looking at disassembled C
code is no picnic! Especially when you don't have all the library
docs. But I soldier on...
Danny
(You guessed it! Remove NOSPAMFOR before emailing.)
| |
|
| I don't know if this will help because my case is slightly different,
but the general procedure (so far...) is to use CreateFile, ReadFile,
WriteFile, and DeviceIoControl.
First, I went to Scanner Properties where I noted the port the scanner
was on. In my case that's "\\.\usbscan0". This is the name I supplied
to CreateFile. (Technically I should have called
IStiDeviceControl::GetMyDevicePortName but I don't know how to do
that. So, for now, I just hardcode it as a literal.)
After that you use the returned handle to invoke DeviceIoControl. In
my case (usbscan.sys) there is a call to "send vendor commands".
That's how I plan to send the low level hardware commands my scanner
speaks.
This is not the level I would like to work at (ideally, I'd like to go
even deeper and not be dependent on usbscan.sys.)
So, in your case, I guess the first question would be if the USB Bar
Code scanner is registered (Control Panel/System/Device Manager/Driver
File Details). If it is then you should be able to get its port from
Scanner Properties. The second question, then, is what are the
commands this driver uses. If the driver is supplied by the vendor you
could probably control the Bar Code reader directly. But, if it uses a
generic driver (like in my case) you could use this generic driver to
send the actual low level (hardware) commands. In either case, you
need to know what they are, of course.
Danny
(You guessed it! Remove NOSPAMFOR before emailing.)
Date: Mon, 28 Mar 2005 18:28:36 -0500
Name: "Ron Weiner" <weinNoSpam1@mindspring.com>
[color=darkred]
>Mark
>
>Wonder if I could jump in here. I am also looking to interface an app I am
>writing with a USB Bar Code scanner. Right now I am using the scanner in
>"keyboard wedge mode". The problem with this is making sure I have my app
>in a position to actually see the keystrokes when they come down the pipe.
>If the focus on my main form is on it WebBrowser control the form is totally
>BLIND to the keystrokes (even though I have KeyPreview set to True).
>
>Sooo.... I am thinking that if I can communicate directly with the darn
>thing via the USB bus I can (hopefully) have my code shovel bytes into a
>buffer that I could poll from time to time to get the scanned codes. Would
>be even better if I could raise an event from my shoveling code when the bar
>code scanner sends the "STOP" code, so my main processing loop can do its
>thing, and clear out the buffer.
>
>Can this be done using VB6 to make various and sundry API calls? If so can
>you point me into the right direction.
>
>Thanks
>
>Ron W
>
>"Mark Yudkin" <myudkinATcompuserveDOTcom@boing.org> wrote in message
>news:uN4u7r2MFHA.2656@TK2MSFTNGP10.phx.gbl...
>a
>you
>you
Danny
(You guessed it! Remove NOSPAMFOR before emailing.)
| |
| Sam Hobbs 2005-03-30, 4:01 pm |
| "Danny" <NOSPAMFORdaniel_ahorn@yahoo.com> wrote in message
news:it9j41h4ga7 7v22idt1alifosvkv5ss@
4ax.com...
>
> I don't think it's that hard if all we want is just to talk to the USB
> device directly. The hard part is interfacing with Windows for all the
> (from our view) "bloat" such as PnP support, etc.
Are you sure or are you guessing? Do you know if a Windows device driver is
more complicated than an equivalent Unix/Linux device driver? My guess (yes
I am guessing) is that a Windows device driver is not significantly more
complicated than an equivalent Unix/Linux device driver. Also, if you were
to write a device driver, it is unlikely you would have to write a device
driver. It is likely you can use a sample in the DDK and modify it as
needed.
| |
|
| Date: Wed, 30 Mar 2005 10:46:55 -0800
Name: "Sam Hobbs" <samuel@social.rr.com_change_social_to_socal>
>
>Are you sure or are you guessing?
I'm absolutely sure I'm guessing! ;o) But seriously...
>Do you know if a Windows device driver is
>more complicated than an equivalent Unix/Linux device driver? My guess (yes
>I am guessing) is that a Windows device driver is not significantly more
>complicated than an equivalent Unix/Linux device driver. Also, if you were
>to write a device driver, it is unlikely you would have to write a device
>driver.
To avoid confusion (in my book) a driver is a direct interface with
the hardware abstracting it to provide the OS with a standardized view
of the hardware.
So, in that respect I don't want to write a driver because I don't
intend to provide the OS with any services, which should simplify
things immensely. Nor do I want to program the chip directly (why
re-invent the wheel). I only want access to the actual driver in order
to use the minimal subset of functions I need.
In plain speaking it boils down to this:
There is a driver which talks to the chip directly. On top of it is a
maze of "software drivers" arranged in a hierarchical stack to provide
assorted services at each layer. A lion share of these has to do with
babysitting the OS and has very little (nothing, actually) to do with
actual USB devices.
Since (in my particular case) I don't really care for all of those
OS-related functions (because I don't want to integrate my program
with the OS) and just want to talk to the device directly, all I need
is to be able to send commands to the device and receive stuff back.
>It is likely you can use a sample in the DDK and modify it as
>needed.
Unfortunately, I don't have the DDK. Or, more accurately, the DDKs I
have are from the original VB6 MSDN CDs and are hopelessly out of date
(USB hasn't even been invented back then).
But that's not necessarily a problem in itself because most of the DDK
has to do with interfacing with the OS.
Danny
(You guessed it! Remove NOSPAMFOR before emailing.)
| |
| Jim Mack 2005-03-31, 8:59 pm |
| Danny wrote:
>
>
> To avoid confusion (in my book) a driver is a direct interface with
> the hardware abstracting it to provide the OS with a standardized view
> of the hardware.
Used to be, that was a reasonable definition. Now, however, you should
just think of it as anything that has to run in ring 0 (kernel mode).
That would include things like 'filter drivers' and the like, or
anything that has to insert itself between two kernel-mode components.
> So, in that respect I don't want to write a driver because I don't
> intend to provide the OS with any services, which should simplify
> things immensely. Nor do I want to program the chip directly (why
> re-invent the wheel). I only want access to the actual driver in order
> to use the minimal subset of functions I need.
But if the device (or driver) you want to talk to doesn't expose a ring
3 (user-mode) interface, you have no choice but to interact with it at
ring 0. And that means writing a kernel-mode component, no matter
whether you call it a driver or not.
There are hacks to allow you to access ports etc that are protected
(owned by ring 0 components), but without knowing the details of your
task I couldn't say whether they'd be appropriate.
Anyway, good luck.
--
Jim Mack
MicroDexterity Inc
www.microdexterity.com
| |
| Mark Yudkin 2005-04-01, 4:01 am |
| Yes, WIA needs Windows ME, not Windows 98. STI is a user mode driver model
designed to support TWAIN and other user APIs. You code an STI user mode
device driver when you really know what you're doing (e.g. you built the
hardware) and is not for the faint of heart. It is hardly a job for VB6.
The APIs (declares etc) are part of the DDK, but are for C[++] of course.
Coding a native USB driver is even more complicated than a user-mode STI
driver. You are definitely on the wrong forum if you want to do this. Start
by reading the section in the DDK "System Support for Buses" - "USB".
If all you want to do is prove a TWAIN bug (unlikely) or a scanner-specific
driver bug (more likely), you'd be better off reproducing your problem and
contacting the manufacturer. Of course, being on an obsolete version of
DOS-based Windows may mean you get a "no longer supported" response.
If all you want to do us do more than TWAIN can, using WIA on WME / WXP is a
better bet. Otherwise you can try to use the Sill Image COM interfaces - but
again, these are not really amenable to VB6 (use C++).
"Danny" <NOSPAMFORdaniel_ahorn@yahoo.com> wrote in message
news:3euf41pbicgbemalak3jggbojhefkg649g@
4ax.com...
> No, it's a commercial scanner, but I'm getting some strange results
> (real pedantic stuff, though, after examining 16-bit histograms). I
> suspect the culprit is TWAIN so to confirm that I would like to get
> unadulterated, raw, pure data from the scanner.
>
> But more importantly, the low level commands have abilities (not
> capabilities) which TWAIN "hides". By going below TWAIN I should be
> able to make use of them too.
>
> Regarding WIA, if I read the documentation correctly WIA doesn't apply
> to W98, so I appear to be stuck with STI.
>
> So, do you happen to have some examples of how to make IStiUSD::,
> IStiDeviceControl:: calls in VB6? Specifically, which declares do I
> need?
>
> At the root of this is a more basic question I have been wrestling
> with for some time. I'd like to work at a level above the hardware
> (and leave talking to the USB controller chip to the OS) but below any
> drivers (which entangle me in the many abstraction layers of the USB
> paradigm). I'd like to work at an intermediate level where bytes are
> just bytes...
>
> Danny
>
> (You guessed it! Remove NOSPAMFOR before emailing.)
>
> Date: Mon, 28 Mar 2005 09:52:40 +0200
> Name: "Mark Yudkin" <myudkinATcompuserveDOTcom@boing.org>
>
>
>
> Danny
>
> (You guessed it! Remove NOSPAMFOR before emailing.)
| |
|
| Thanks for the tips!
The manufacturer so-called "support" is unfortunately quite appalling.
It caters to people with questions like "why does my scanner stop
working when I press the OFF switch"... :-/
But problems like linear scan gamma artifacts (which in theory is
impossible, hence the bug) are way over their heads although they
aren't admitting it. Since gamma is done within TWAIN I'm quite
certain that's where the bug is.
I do realize that writing a driver is complicated. However, I only
want to "wedge in" on top the (true) hardware driver, but below the OS
superimposed "abstraction bloat". All I want is to send and receive
"stuff" to and from the desired USB device, using the existing low
level (hardware) driver.
I've since found out that the scanner uses a generic "software driver"
(usbscan0.sys) which has a well documented interface. So using
DeviceIoControl and IOCTL_SEND_USB_REQUEST I should be able to send
commands. Well, that's the theory...
But you're right. Wrestling C++ definitions over to VB is a project in
its own right.
Danny
(You guessed it! Remove NOSPAMFOR before emailing.)
Date: Fri, 1 Apr 2005 08:16:16 +0200
Name: "Mark Yudkin" <myudkinATcompuserveDOTcom@boing.org>
[color=darkred]
>Yes, WIA needs Windows ME, not Windows 98. STI is a user mode driver model
>designed to support TWAIN and other user APIs. You code an STI user mode
>device driver when you really know what you're doing (e.g. you built the
>hardware) and is not for the faint of heart. It is hardly a job for VB6.
>
>The APIs (declares etc) are part of the DDK, but are for C[++] of course.
>
>Coding a native USB driver is even more complicated than a user-mode STI
>driver. You are definitely on the wrong forum if you want to do this. Start
>by reading the section in the DDK "System Support for Buses" - "USB".
>
>If all you want to do is prove a TWAIN bug (unlikely) or a scanner-specific
>driver bug (more likely), you'd be better off reproducing your problem and
>contacting the manufacturer. Of course, being on an obsolete version of
>DOS-based Windows may mean you get a "no longer supported" response.
>
>If all you want to do us do more than TWAIN can, using WIA on WME / WXP is a
>better bet. Otherwise you can try to use the Sill Image COM interfaces - but
>again, these are not really amenable to VB6 (use C++).
>
>"Danny" <NOSPAMFORdaniel_ahorn@yahoo.com> wrote in message
> news:3euf41pbicgbemalak3jggbojhefkg649g@
4ax.com...
Danny
(You guessed it! Remove NOSPAMFOR before emailing.)
| |
|
| Date: Thu, 31 Mar 2005 16:18:41 -0500
Name: "Jim Mack" <jmack@mdxi.nospam.com>
>
>Used to be, that was a reasonable definition. Now, however, you should
>just think of it as anything that has to run in ring 0 (kernel mode).
>That would include things like 'filter drivers' and the like, or
>anything that has to insert itself between two kernel-mode components.
I know, that's exactly the problem as the definitions slowly morph
until they mean exactly the opposite... :-/
>But if the device (or driver) you want to talk to doesn't expose a ring
>3 (user-mode) interface, you have no choice but to interact with it at
>ring 0. And that means writing a kernel-mode component, no matter
>whether you call it a driver or not.
>
>There are hacks to allow you to access ports etc that are protected
>(owned by ring 0 components), but without knowing the details of your
>task I couldn't say whether they'd be appropriate.
The DDK refers to both kernel mode and user mode "minidrivers" so in
theory it should be possible to write a bare-bones user mode
minidriver. Especially, since I only need a very limited subset of
functions.
But that's not really what I want to do. All I want is to use the
existing low level hardware driver hiding below all the "software
drivers".
>Anyway, good luck.
Thanks! I'm hopelessly lost, by making good time! ;o)
Seriously, though, as I write elsewhere I'm almost there but using a
generic driver. Not quite as low as I'd like but should do the trick.
I might need help wrestling DeviceIoControl over to VB but I'll post
that when I need it.
Danny
(You guessed it! Remove NOSPAMFOR before emailing.)
| |
| Mark Yudkin 2005-04-06, 12:46 pm |
| Actually, TWAIN does not do Gamma correction. There are very few scanner
drivers nowadays that do any form of colour correction, even on XP with its
builtin ICM support. For example, HP used to have colour correction in old
scanner drivers, but removed it in newer drivers. The market has apparently
decided that it is the job of the imaging application to address colour
matching issues. For example, Adobe Photoshop has extensive support for
this.
Anyway, if you're trying to work around colour artefacts, you're going about
it the wrong way. And there's no point reporting a bug, as it is working as
designed. This applies to multi $10K scanners, not just low-end drivers too.
"Danny" <NOSPAMFORdaniel_ahorn@yahoo.com> wrote in message
news:gq6r41pnh33foo6a8u2r299tgdkku2ap4g@
4ax.com...
> Thanks for the tips!
>
> The manufacturer so-called "support" is unfortunately quite appalling.
> It caters to people with questions like "why does my scanner stop
> working when I press the OFF switch"... :-/
>
> But problems like linear scan gamma artifacts (which in theory is
> impossible, hence the bug) are way over their heads although they
> aren't admitting it. Since gamma is done within TWAIN I'm quite
> certain that's where the bug is.
>
> I do realize that writing a driver is complicated. However, I only
> want to "wedge in" on top the (true) hardware driver, but below the OS
> superimposed "abstraction bloat". All I want is to send and receive
> "stuff" to and from the desired USB device, using the existing low
> level (hardware) driver.
>
> I've since found out that the scanner uses a generic "software driver"
> (usbscan0.sys) which has a well documented interface. So using
> DeviceIoControl and IOCTL_SEND_USB_REQUEST I should be able to send
> commands. Well, that's the theory...
>
> But you're right. Wrestling C++ definitions over to VB is a project in
> its own right.
>
> Danny
>
> (You guessed it! Remove NOSPAMFOR before emailing.)
>
> Date: Fri, 1 Apr 2005 08:16:16 +0200
> Name: "Mark Yudkin" <myudkinATcompuserveDOTcom@boing.org>
>
>
>
> Danny
>
> (You guessed it! Remove NOSPAMFOR before emailing.)
| |
| Danny 2005-04-06, 12:46 pm |
| Your ability to be so certain about a long distance diagnosis with so
little first hand data is admirable. ;o) I, on the other hand, just
have a linear scan and a 16-bit histogram. And all I can say from that
is that no scanner has ever been intentionally designed to produce
such a histogram at gamma 1.0.
Nominally, gamma is beyond the scope of TWAIN. However, that's not how
Nikon implemented it. The library in question *.md3 (called the MAID
module) does implement gamma as well as a slew of other vendor
specific functions (Kodachrome mode, DEE, etc) and it's called by
NikonScan whether it runs standalone or is invoked as a TWAIN module.
Most, if not all, "TWAIN drivers" these days are actually a
combination of TWAIN and rudimentary image editing, rolled into one.
This is not a color correction issue either, but gamma-like artifacts
at linear scan. This should not happen. If all other options are
turned off (they are) a scan at gamma 1.0 should not have any "spikes"
or "gaps" as evident in this case when examining 16-bit histograms.
Moreover, the red channel has spikes, the blue channel has gaps and
the green channel is as it should be. This is *very* odd! So there is
something seriously fishy going on.
Therefore, I'd like to perform a raw scan without any Nikon software
anywhere near by (except for the firmware within the scanner). If the
artifacts are still present - which I doubt - then Nikon has a much
bigger problem...
Danny
(You guessed it! Remove NOSPAMFOR before emailing.)
Date: Sun, 3 Apr 2005 10:37:04 +0200
Name: "Mark Yudkin" <myudkinATcompuserveDOTcom@boing.org>
[color=darkred]
>Actually, TWAIN does not do Gamma correction. There are very few scanner
>drivers nowadays that do any form of colour correction, even on XP with its
>builtin ICM support. For example, HP used to have colour correction in old
>scanner drivers, but removed it in newer drivers. The market has apparently
>decided that it is the job of the imaging application to address colour
>matching issues. For example, Adobe Photoshop has extensive support for
>this.
>
>Anyway, if you're trying to work around colour artefacts, you're going about
>it the wrong way. And there's no point reporting a bug, as it is working as
>designed. This applies to multi $10K scanners, not just low-end drivers too.
>
>"Danny" <NOSPAMFORdaniel_ahorn@yahoo.com> wrote in message
> news:gq6r41pnh33foo6a8u2r299tgdkku2ap4g@
4ax.com...
Danny
(You guessed it! Remove NOSPAMFOR before emailing.)
| |
| Mark Yudkin 2005-04-06, 12:46 pm |
| If you're seeing spikes or gaps in the scan data for specific colours, the
first question should be "have you had the scanner serviced?" Such effects
sound like (long distance diagnosis) a hardware defect (faulty CCDs), and
your local Nikon service branch should be able to perform electronic
validation of the scanner's circuits without reference to any software
drivers.
In any case, there's no such thing as a "linear scan", even with very
expensive scanners. No scanner gets colours correct over the full range it
supports; the quality does of course vary, typically proportionally to the
amount you spend. The rudimentary colour correction in manufacturer's
drivers is also typically just that.
Going back to your original issue. Since you're trying to "diagnose" a
single scanner (model), you'd be a lot better off attaching it to an XP
system and using WIA to drive the image capture than trying to code a
user-mode STI driver in VB6 under Windows 98.
"Danny" <NOSPAMFORdaniel_ahorn@yahoo.com> wrote in message
news:ff8051dhr5b9cuul4e0lohfio9p4qfk8sa@
4ax.com...
> Your ability to be so certain about a long distance diagnosis with so
> little first hand data is admirable. ;o) I, on the other hand, just
> have a linear scan and a 16-bit histogram. And all I can say from that
> is that no scanner has ever been intentionally designed to produce
> such a histogram at gamma 1.0.
>
> Nominally, gamma is beyond the scope of TWAIN. However, that's not how
> Nikon implemented it. The library in question *.md3 (called the MAID
> module) does implement gamma as well as a slew of other vendor
> specific functions (Kodachrome mode, DEE, etc) and it's called by
> NikonScan whether it runs standalone or is invoked as a TWAIN module.
> Most, if not all, "TWAIN drivers" these days are actually a
> combination of TWAIN and rudimentary image editing, rolled into one.
>
> This is not a color correction issue either, but gamma-like artifacts
> at linear scan. This should not happen. If all other options are
> turned off (they are) a scan at gamma 1.0 should not have any "spikes"
> or "gaps" as evident in this case when examining 16-bit histograms.
>
> Moreover, the red channel has spikes, the blue channel has gaps and
> the green channel is as it should be. This is *very* odd! So there is
> something seriously fishy going on.
>
> Therefore, I'd like to perform a raw scan without any Nikon software
> anywhere near by (except for the firmware within the scanner). If the
> artifacts are still present - which I doubt - then Nikon has a much
> bigger problem...
>
> Danny
>
> (You guessed it! Remove NOSPAMFOR before emailing.)
>
> Date: Sun, 3 Apr 2005 10:37:04 +0200
> Name: "Mark Yudkin" <myudkinATcompuserveDOTcom@boing.org>
>
>
>
> Danny
>
> (You guessed it! Remove NOSPAMFOR before emailing.)
| |
|
| It's virtually impossible for this to be a hardware problem. The
symmetry (red up, blue down, and green nominal) and the gamma-like
spread of the artifacts clearly points to software. Furthermore,
turning on Kodachrome mode (a strictly software feature) makes blue
channel nominal (no spikes or gaps) but corrupts the green!? So, quite
clearly, the problem is in software. The only question is whether this
is the TWAIN driver or the low level firmware. My bet is on the TWAIN.
I'm afraid there is such a thing as a linear scan. It's common
terminology for scanning at gamma 1.0 (also known as linear gamma).
This has nothing to do with CCD wells, dark current, spectral
characteristics of light sources or anything else. A linear scan
simply refers to the fact that no gamma correction has taken place.
It's not likely an XP machine would make any difference because WIA
sits on top of STI. So, by dealing with STI directly, I eliminate
another layer of abstraction (WIA) and a possible cause of more
software problems.
Anyway, I did manage rudimentary access using DeviceIoControl and
"\\.\usbscan0" as port name although I haven't managed to actually
perform a scan yet.
Danny
(You guessed it! Remove NOSPAMFOR before emailing.)
Date: Wed, 6 Apr 2005 09:23:06 +0200
Name: "Mark Yudkin" <myudkinATcompuserveDOTcom@boing.org>
[color=darkred]
>If you're seeing spikes or gaps in the scan data for specific colours, the
>first question should be "have you had the scanner serviced?" Such effects
>sound like (long distance diagnosis) a hardware defect (faulty CCDs), and
>your local Nikon service branch should be able to perform electronic
>validation of the scanner's circuits without reference to any software
>drivers.
>
>In any case, there's no such thing as a "linear scan", even with very
>expensive scanners. No scanner gets colours correct over the full range it
>supports; the quality does of course vary, typically proportionally to the
>amount you spend. The rudimentary colour correction in manufacturer's
>drivers is also typically just that.
>
>Going back to your original issue. Since you're trying to "diagnose" a
>single scanner (model), you'd be a lot better off attaching it to an XP
>system and using WIA to drive the image capture than trying to code a
>user-mode STI driver in VB6 under Windows 98.
>
>"Danny" <NOSPAMFORdaniel_ahorn@yahoo.com> wrote in message
> news:ff8051dhr5b9cuul4e0lohfio9p4qfk8sa@
4ax.com...
Danny
(You guessed it! Remove NOSPAMFOR before emailing.)
| |
| Mark Yudkin 2005-04-08, 9:00 am |
| What you call "a linear scan" is merely a scan in which the software
performs no gamma correction. As such, we're using the same term to mean two
different things, your meaning has nothing to do with colour accuracy or its
use in the professional literature, and is essentially pointless as it does
nothing to ensure the colours are even similar. See
http://www.flexography.org/flexo/article.cfm?ID=10.
My suggestion for using WIA is to allow you to use a non-TWAIN driver,
thereby bypassing the TWAIN driver you are blaming. You could also use an
application that supplies its own mini-TWAIN driver, there are a lot of
these on the market at all sorts of prices.
Your conclusions pointing to software can be summarized as "dogs bite
postmen, dogs have teeth, you have teeth, therefore you bite postmen".
Accordingly, there is no point in my trying to help you (even though I'm not
a postman), and this is my last response.
"Danny" <NOSPAMFORdaniel_ahorn@yahoo.com> wrote in message
news:jl5851d6i1sekqtatnotp5kvm20al10o61@
4ax.com...
> It's virtually impossible for this to be a hardware problem. The
> symmetry (red up, blue down, and green nominal) and the gamma-like
> spread of the artifacts clearly points to software. Furthermore,
> turning on Kodachrome mode (a strictly software feature) makes blue
> channel nominal (no spikes or gaps) but corrupts the green!? So, quite
> clearly, the problem is in software. The only question is whether this
> is the TWAIN driver or the low level firmware. My bet is on the TWAIN.
>
> I'm afraid there is such a thing as a linear scan. It's common
> terminology for scanning at gamma 1.0 (also known as linear gamma).
> This has nothing to do with CCD wells, dark current, spectral
> characteristics of light sources or anything else. A linear scan
> simply refers to the fact that no gamma correction has taken place.
>
> It's not likely an XP machine would make any difference because WIA
> sits on top of STI. So, by dealing with STI directly, I eliminate
> another layer of abstraction (WIA) and a possible cause of more
> software problems.
>
> Anyway, I did manage rudimentary access using DeviceIoControl and
> "\\.\usbscan0" as port name although I haven't managed to actually
> perform a scan yet.
>
> Danny
>
> (You guessed it! Remove NOSPAMFOR before emailing.)
>
> Date: Wed, 6 Apr 2005 09:23:06 +0200
> Name: "Mark Yudkin" <myudkinATcompuserveDOTcom@boing.org>
>
>
>
> Danny
>
> (You guessed it! Remove NOSPAMFOR before emailing.)
| |
|
| There's only *one* definition of linear scan, and that's a scan using
linear gamma (1.0). Period. Any other "definition" or understanding is
simply factually wrong.
You also keep bringing up color accuracy even though it has absolutely
nothing to do with the subject at hand. The purpose of a linear scan
is *not* to achieve "perfect" color accuracy but to eliminate as many
variables as possible i.e., a baseline, in order to perform an
objective analysis.
This was never about color accuracy but about gamma-like histogram
artifacts appearing where they should not be appearing. That's all.
Where I do agree, however, is that this has gone way off topic...
Danny
(You guessed it! Remove NOSPAMFOR before emailing.)
Date: Fri, 8 Apr 2005 09:20:01 +0200
Name: "Mark Yudkin" <myudkinATcompuserveDOTcom@boing.org>
[color=darkred]
>What you call "a linear scan" is merely a scan in which the software
>performs no gamma correction. As such, we're using the same term to mean two
>different things, your meaning has nothing to do with colour accuracy or its
>use in the professional literature, and is essentially pointless as it does
>nothing to ensure the colours are even similar. See
>http://www.flexography.org/flexo/article.cfm?ID=10.
>
>My suggestion for using WIA is to allow you to use a non-TWAIN driver,
>thereby bypassing the TWAIN driver you are blaming. You could also use an
>application that supplies its own mini-TWAIN driver, there are a lot of
>these on the market at all sorts of prices.
>
>Your conclusions pointing to software can be summarized as "dogs bite
>postmen, dogs have teeth, you have teeth, therefore you bite postmen".
>Accordingly, there is no point in my trying to help you (even though I'm not
>a postman), and this is my last response.
>
>"Danny" <NOSPAMFORdaniel_ahorn@yahoo.com> wrote in message
> news:jl5851d6i1sekqtatnotp5kvm20al10o61@
4ax.com...
Danny
(You guessed it! Remove NOSPAMFOR before emailing.)
|
|
|
|
|