hpoj-devel — HPOJ development/support list

Re: [hpoj-devel] USB Cold Plug Etc.

[<pa...@rc...>]

Hi, Allen.

Allen Barnett wrote in response to me:
> >  If you're interested I can forward
> > you some more information provided by HP, with the stipulation that you
> > can't re-distribute the documents themselves.
> Sure, I'd like to see them. Is a more formal arrangement necessary?
No, just keep the already-mentioned rules in mind (which didn't come from me).
I'll send the documents out separately.

> With respect to PML traps: Is it necessary that the kernel interface
> support poll()/select()? I had an e-mail exchange with Tim Waugh a while
> ago about the possiblilty of adding this to the line printer (lp)
> device. He said it was trivial to add, but most parallel port devices
> didn't implement the necessary behavior properly. So, I was wondering if
> a poll()/select() interface was necessary (or perhaps I really mean to
> say: optimal), are USB devices more likely to work properly?
ptal-mlcd drives the parallel port directly, bypassing the kernel, so poll()
and select() support is irrelevant.  For USB it does use a /dev/usb/lp*
device driver and relies on select() in that case.  However, there were some
bugs in the select support and reverse (peripheral-to-host) data reading
functionality.  My fixes went into 2.4.2 and will go into 2.2.19, which is
why I indicated those were the minimum supported versions.

The low-level reverse data support is critical to a much greater extent than
just supporting PML traps, which are just data packets going over the PML
channel.  Multiple channels can be open and transferring data in either or
both directions.  The command channel is open all the time to allow data
channels to be opened or closed and to send credits back and forth.  See the
MLC and 1284.4 (http://hpoj.sourceforge.net/links.shtml) specs for more
information.

> FWIW, I recompiled the basic USB driver (usbcore.o) as a module
> instead of having it built into the kernel. The printer module is now
> loaded automatically (along with the drivers for anything else plugged
> in) when hotplug is started. 
I'm glad it's working for you now.  I can see how there could be a problem
because some things are compiled in and others are modular.  I would expect
that it would also work if everything were compiled into the kernel, but
all-modular is more flexible, and that's what I usually prefer for myself.

David

Re: [hpoj-devel] USB Cold Plug Etc.

[Allen B. <ba...@lo...>]

FWIW, I recompiled the basic USB driver (usbcore.o) as a module instead
of having it built into the kernel. The printer module is now loaded
automatically (along with the drivers for anything else plugged in) when
hotplug is started.

Allen

"PASCHAL,DAVID (HP-Roseville,ex1)" wrote:
> Allen Barnett wrote:
> > I cold started my machine this morning and was surprised to see that the
> > USB printer.o module was not 'cold plugged' as the machine booted. If I
> > pull the USB plug and reinsert it, the printer.o module is loaded OK (by
> > /sbin/hotplug?), after which ptal-mlc and ptal-printd can be started OK.
> > Is there a patch to the USB printer.c module for the G85 (or similar)
> > which can cause it to be loaded at boot time? (There's some info in the
> > hotplug README about using the 'usbmodules' command if a module is not
> > loading at boot time. Is this the way to go?)
> I don't think the problem is in printer.c.  The "hot-plugging" section of
> the FAQ page at http://www.linux-usb.org mentions the term "cold-plugging",
> which is what you're having a problem with, but I can't find any specific
> information about it.  It sounds like you're reading the right information,
> though, so run whatever commands you need to in order to make it work.  :-)
> I personally avoid the whole mess by insmoding all the necessary modules at
> startup.
>

Re: [hpoj-devel] USB Cold Plug Etc.

[Allen B. <ba...@lo...>]

"PASCHAL,DAVID (HP-Roseville,ex1)" wrote:
> > And yet another dumb question: what are 'PML' and 'MFPDTF'
> > mentioned on
> > the TODO page at hpoj.sourceforge.net?
... interesting details deleted ...
>  If you're interested I can forward
> you some more information provided by HP, with the stipulation that you
> can't re-distribute the documents themselves.

Sure, I'd like to see them. Is a more formal arrangement necessary?

With respect to PML traps: Is it necessary that the kernel interface
support poll()/select()? I had an e-mail exchange with Tim Waugh a while
ago about the possiblilty of adding this to the line printer (lp)
device. He said it was trivial to add, but most parallel port devices
didn't implement the necessary behavior properly. So, I was wondering if
a poll()/select() interface was necessary (or perhaps I really mean to
say: optimal), are USB devices more likely to work properly?

Thanks,
Allen

RE: [hpoj-devel] USB Cold Plug Etc.

[PASCHAL,DAVID (HP-Roseville,ex1) <dav...@hp...>]

Hi, Allen.

Allen Barnett wrote:
> I cold started my machine this morning and was surprised to 
> see that the
> USB printer.o module was not 'cold plugged' as the machine 
> booted. If I
> pull the USB plug and reinsert it, the printer.o module is 
> loaded OK (by
> /sbin/hotplug?), after which ptal-mlc and ptal-printd can be 
> started OK.
> Is there a patch to the USB printer.c module for the G85 (or similar)
> which can cause it to be loaded at boot time? (There's some 
> info in the
> hotplug README about using the 'usbmodules' command if a module is not
> loading at boot time. Is this the way to go?)
I don't think the problem is in printer.c.  The "hot-plugging" section of
the FAQ page at http://www.linux-usb.org mentions the term "cold-plugging",
which is what you're having a problem with, but I can't find any specific
information about it.  It sounds like you're reading the right information,
though, so run whatever commands you need to in order to make it work.  :-)
I personally avoid the whole mess by insmoding all the necessary modules at
startup.

> I was also wondering what the status of FAXing to and from 
> the PC. Soon?
> Possible?
As far as I know, fax-receive isn't supported in the G or K series firmware,
so it won't be possible to support it in software either (but fax-send is
possible).  I need to finish implementing PML (see below) before I can
implement broader scanning support or faxing/copying support where possible.
I may provide some quick-and-dirty PML scanning/faxing/copying utilities to
help test the PML support and get that functionality working before I start
writing a fancier implementation.

> I was also wondering about the 'Scan To' button on the front 
> panel. Can
> this be programmed?
Theoretically yes, but I'll have to do some research to find out exactly how
to do it.  I do know it involves PML, especially PML traps.

> And yet another dumb question: what are 'PML' and 'MFPDTF' 
> mentioned on
> the TODO page at hpoj.sourceforge.net?
Not a dumb question at all.  I should explain it better on the web.  PML
stands for Peripheral Management Language, and is a datagram request/reply
management protocol similar to SNMP.  xojpanel (currently disabled in CVS)
uses PML to get the contents of the LCD.  Scanning (non-SCL), faxing, and
copying use PML to set various options, like color depth and resolution and
to start/stop the operation.  PML traps are a mechanism for the peripheral
to notify the host when the value of an object changes so the host doesn't
have to constantly poll.  MFPDTF stands for Multi-Function Peripheral Data
Transfer Format and defines a packet format for scan/fax/copy data.  There's
a small amount of information about these topics under the now outdated
documentation section on the web page.  If you're interested I can forward
you some more information provided by HP, with the stipulation that you
can't re-distribute the documents themselves.

David

[hpoj-devel] USB Cold Plug Etc.

[Allen B. <ba...@lo...>]

I cold started my machine this morning and was surprised to see that the
USB printer.o module was not 'cold plugged' as the machine booted. If I
pull the USB plug and reinsert it, the printer.o module is loaded OK (by
/sbin/hotplug?), after which ptal-mlc and ptal-printd can be started OK.
Is there a patch to the USB printer.c module for the G85 (or similar)
which can cause it to be loaded at boot time? (There's some info in the
hotplug README about using the 'usbmodules' command if a module is not
loading at boot time. Is this the way to go?)

I was also wondering what the status of FAXing to and from the PC. Soon?
Possible?

I was also wondering about the 'Scan To' button on the front panel. Can
this be programmed?

With sufficient direction, I would be glad to work on any of these
things. (As Ringo says in the film "Yellow Submarine", "I'm a born
button pusher.")

And yet another dumb question: what are 'PML' and 'MFPDTF' mentioned on
the TODO page at hpoj.sourceforge.net?

Thanks,
Allen

Re: [hpoj-devel] Scanning with T65

[<pa...@rc...>]

Gerard H. Pille wrote:
> I'd just like to know if there is any hope left.
> 
> I was also wondering if I could be of any assistance, debugging or even
> writing code myself, I've got some programming experience (23 years, 12+
> in C).  I'm running a 2.4.2 SMP kernel.

Hi, Gerard.  Broader scanning support is on my to-do list, but first I need
to finish developing the low-level support (namely PML) needed to scan on
the class of peripherals that includes the OfficeJet T series.  A month or
so ago James Klicman started writing a simple PML-scanning program, but he
ran into problems due to bugs in the kernel-mode I/O drivers (ieee12844*.o),
which I'm working on replacing with a user-mode driver (ptal-mlcd).  At the
moment there isn't really any work I can delegate, but you're certainly
welcome to help test printing at least with ptal-mlcd, which is checked into
CVS.

David

[hpoj-devel] ptal-printd fixes

[<pa...@rc...>]

Hi,

I just checked in some more changes to ptal-printd to make it more robust
about handling runtime errors, instead of just exiting.

If it can't open the print channel (possibly because the device is powered
off), then it now delays and retries indefinitely.  The delay defaults to
30 seconds and can be changed by the "-retrydelay <seconds>" parameter.

If a write to the print channel fails during a print job (possibly due to a
communication error or power-down), then it bit-buckets the rest of the
current print job.  It may also bit-bucket successive print jobs that are
already enqueued, because it can't reliably detect job boundaries in that
case.  Once it detects a job boundary (an EOF on the named pipe), then it
should stop bit-bucketing.

I think I already mentioned that I changed ptal-printd to fork itself into
the background by default (changeable by the "-nofork" switch).

We had a pretty big discussion about these ptal-printd issues several months
ago right after I released 0.7, and I think I have now addressed all of them.
I would be interested to know what people think of these fixes, and if
there's anything else I should try to change.

I still plan to check in an "init" script to start and stop ptal-mlcd and
ptal-printd.  I'll probably provide one generic (distribution-independent)
script for both daemons (${prefix}/sbin/ptal-init), based on input from a
configuration file in /etc.  Distribution-dependent scripts can then be
written to invoke the generic script as needed and take care of details like
updating /var/run and printing RedHat-style "OK"/"FAILED" status messages.

David

Re: [hpoj-devel] new "ptal-mlcd" I/O driver checked into CVS

[<pa...@rc...>]

Alexander Zimmermann wrote:
> The current CVS code with ptal-mlcd compiles and works fine (printing
> and scanning) on my system:
> 
>   RedHat 7.0, kernel 2.2.16 SMP, gcc 2.95.2, glibc 2.2
>   G85 connected to parport 0 (in ECP mode)
> 
> Color scanning of one A4 page at 75 dpi lasts about 1 minute.
> (Is that a normal time?)
Hi, Alexander.  Thanks for the report.  Parallel-port I/O with ptal-mlcd is
slower in general than it was with the old kernel-mode drivers.  (I too was
disappointed when I discovered that.)  I will do some optimization eventually
to try to improve performace, but in any case at least it should be a lot
more robust with SMP than the old drivers.  In the meantime, if your system
supports USB then you can get much better performance that way, but you'll
need to upgrade drivers/usb/printer.c in the kernel.

David

Re: [hpoj-devel] new "ptal-mlcd" I/O driver checked into CVS

[Joe P. <joe...@sn...>]

On Tuesday 13 March 2001 04:03 am, David Paschal wrote:

<...>
> > I haven't tried to install or test the package yet. I'll probably wait
> > until the io.h work-around arrives.
>
> I just checked it into CVS.  Please do a "cvs update" and try it now.
>

David:

The package builds for me now with no errors.

-- 
Joe

Re: [hpoj-devel] new "ptal-mlcd" I/O driver checked into CVS

[Alexander Z. <Ale...@fm...>]

On  9 Mar, PASCHAL,DAVID (HP-Roseville,ex1) wrote:
> I'm pleased to announce that the new "ptal-mlcd" I/O driver I've talked a
> lot about lately is now checked into CVS.

Just FYI:

The current CVS code with ptal-mlcd compiles and works fine (printing
and scanning) on my system:

  RedHat 7.0, kernel 2.2.16 SMP, gcc 2.95.2, glibc 2.2
  G85 connected to parport 0 (in ECP mode)

Color scanning of one A4 page at 75 dpi lasts about 1 minute.
(Is that a normal time?)

CU
-- 
Ale...@fm... / "The Street finds its own uses 
http://www.fmi.uni-passau.de/~zimmerma/ for technology." -- William
for PGP public key finger            / Gibson 
zim...@yo...     / 

Re: [hpoj-devel] new "ptal-mlcd" I/O driver checked into CVS

[<pa...@rc...>]

Hi, Joe.

Joe Piolunek wrote in response to me:
> > Could you send your version of
> > sys/io.h to my non-HP address?  I'd like to diff it against what I have on
> > my system at home.
> 
> Done.
Got it.  Thanks.  It's exactly the same as the version on my 6.2 system, so
it's obviously the difference in compilers that causes the problem.

> I changed io.h to include a space between every instance of '::'. The hpoj 
> package built afterwards with no errors. I didn't want to leave the file like 
> that, so it's back to the original now. If you find a good work-around for 
> the problem, it would be great.
Thanks for the info.

> I haven't tried to install or test the package yet. I'll probably wait until 
> the io.h work-around arrives.
I just checked it into CVS.  Please do a "cvs update" and try it now.

I decided to go with the C wrapper workaround method.  It's only enabled when
necessary, to avoid a performance penalty (however small) when the workaround
isn't needed.  If you're interested, you can try running the configure script
with either the original or "fixed" version of io.h and see that configure
enables or disables the workaround as necessary.  On my system, I simulated
the problem by adding the following three lines to create a "broken" version:
#ifdef __cplusplus
#error Simulating broken C++ compiler
#endif

Thanks for your patience while I fix all of the "but it works on my system"
problems.  :-)

BTW, in case anybody has run into problems building without parallel port
support (./configure --without-par), I fixed some compilation problems in
that scenario also.

David

Re: [hpoj-devel] new "ptal-mlcd" I/O driver checked into CVS

[Joe P. <joe...@sn...>]

On Monday 12 March 2001 02:53 pm, PASCHAL,DAVID (HP-Roseville,ex1) wrote:
 
<...>

> Could you send your version of
> sys/io.h to my non-HP address?  I'd like to diff it against what I have on
> my system at home.

Done.


> (regarding whether putting a space between the double colons fixes the
> problem):

> It would be helpful if you tried it in at least one place, just to see if
> it makes the error in that place go away.  If so, then perhaps I could
> include a "fixed" version as a workaround, although it might not be optimal
> to ship __asm__ statements with a package I want to be as platform
> independent as possible.  :-)

I changed io.h to include a space between every instance of '::'. The hpoj 
package built afterwards with no errors. I didn't want to leave the file like 
that, so it's back to the original now. If you find a good work-around for 
the problem, it would be great.

I haven't tried to install or test the package yet. I'll probably wait until 
the io.h work-around arrives.

-- 
Joe

Re: [hpoj-devel] Success with G85

[Allen B. <ba...@lo...>]

"PASCHAL,DAVID (HP-Roseville,ex1)" wrote:
> 
> Allen Barnett wrote:
> > I installed 0.8 of the OfficeJet drivers per the very detailed
> > instructions in the README files and have successfully
> > scanned from, and
> > printed to, a G85 connected through its USB port.
> 
> Regarding the "very detailed instructions", do you think they are too
> detailed in the README/INSTALL/*-HOWTO files?  I'm thinking they are and
> that I should provide simpler (less detailed) setup instructions there and
> move most of the details into separate manual pages for each daemon or
> application.  Do you have any thoughts one way or the other?


I had to perform each step as outlined in your instructions for both
scanning and printing, so I do not consider them too detailed! I had to
download and install SANE (which is now separated into two pieces, by
the way, sane-backends-1.0.4 and sane-frontends-1.0.4; I still haven't
been able to connect to ftp.mostang.com; I ended up getting the backend
source from TUCOWS). So, I'm not sure how you could simplify them, at
least until distributions catch up with the latest versions of SANE, the
2.4 kernel and so forth. Of course, a GUI installer for the totally
hapless might be nice :-)



> How was your experience with updating printer.c in the Linux kernel source
> (if you weren't already running a recent-enough kernel)?  I'm trying to
> decide if I need to provide a sufficiently up-to-date version with the hpoj
> package so people don't have to mess with downloading and updating their
> kernel (or just extracting that file).

I had actually upgraded to 2.4.2 and installed the hotplug scripts a
couple of days ago for an unrelated reason, so I just had to add the
printer.o module to the kernel config. When I plugged in the USB cable,
hotplug went ahead and loaded the driver. Remarkable.

For comparison, the XFree86 DRI OpenGL driver has a kernel module as
well as user-space components. Both components are provided in the CVS
repository at dri.sourceforge.net. However, some version of the kernel
module also shows up in the kernel source. These occasionally get out of
sync, causing mysterious failures (till someone knocks their head after
checking their X log). If the printer.o module is relatively stable or
at least relatively independent of the user-space driver, then it might
be more convenient to provide it with the HPOJ source, otherwise, I'd
leave it out.

Allen

RE: [hpoj-devel] Success with G85

[PASCHAL,DAVID (HP-Roseville,ex1) <dav...@hp...>]

Allen Barnett wrote:
> I installed 0.8 of the OfficeJet drivers per the very detailed
> instructions in the README files and have successfully 
> scanned from, and
> printed to, a G85 connected through its USB port.
Hi, Allen.  Thanks for your success report.  I'm glad it works for you.
However, I should point out that this is not version "0.8" yet.  My
references to "0.8" on the "Bugs and TODO" page are meant to indicate what
still needs to be done before the code will be ready for me to create and
release a new official package, which will be numbered "0.8".  I can't give
a definite date for that yet but at this point I think June or July is a
realistic goal, given the large amount of new code I just checked in (and
code I still need to write) and the time it will take to work out all the
problems.  Nevertheless, all the testing you can do on the "unstable" code
in CVS will be greatly appreciated.  :-)

Regarding the "very detailed instructions", do you think they are too
detailed in the README/INSTALL/*-HOWTO files?  I'm thinking they are and
that I should provide simpler (less detailed) setup instructions there and
move most of the details into separate manual pages for each daemon or
application.  Do you have any thoughts one way or the other?

How was your experience with updating printer.c in the Linux kernel source
(if you weren't already running a recent-enough kernel)?  I'm trying to
decide if I need to provide a sufficiently up-to-date version with the hpoj
package so people don't have to mess with downloading and updating their
kernel (or just extracting that file).

> It takes a relatively long time (~4.5 minutes) to scan at 600 dpi. The
> head moves a little bit forward, then backs up a couple of times, then
> goes a little bit further. Is this normal behavior? (Lower 
> resolutions,
> even 300 dpi, seem to zip right through).
The higher the resolution, the more data that needs to be transferred.  At
some point as you increase the resolution the I/O becomes the bottleneck,
rather than the scanner, so the scan-head backtracking you observed is to be
expected.  600dpi is overkill for most applications anyway.  I'm not an
expert on the subject, but I think 150dpi is probably sufficient for photos.
There are various "scanning FAQs" available, though I don't know where
offhand.  I think the on-line documentation to the "xsane" frontend
application has references to some of these.

> (Also, what's the 
> best tool to
> look at a 107Mb TIFF file :-)
For simple viewing I used to use "xv" until RedHat stopped providing it.  I
now use Electric Eyes ("ee"), but I created a xv->ee symlink because I was
so accustomed to typing "xv".  :-)

> The RedHat printtool test page shows the red hat logo and a set of
> sample colors. The red in the "red hat" is a reasonably 
> bright, however
> the red in the sample color bar is much too dark. I guess this is a
> gamma problem, but why would the two reds look so different? 
> Presumably,
> the red in the logo is from a PostScript bitmap and the red 
> in the color
> sample is just a filled rectangle. Is one gamma correction going to
> affect both?
You might get slightly better results by tweaking the gamma correction, but
I don't think it will help much.  The new drivers under development by HP at
http://hpinkjet.sourceforge.net should provide much better output when
they're released.

When I print the RedHat test page on a PostScript Color LaserJet 4500, the
colors come out correctly, but there is a slight difference between the two
reds.  RGB->CMYK color mapping is hard to do, and a slight difference on one
output device can be greatly magnified on another device using a
less-optimized mapping.

> Finally, what does MLC stand for?
Multiple Logical Channels.  MLC is an HP transport protocol for packetizing
multiple data streams, such as printing and scanning, over a single link,
such as parallel or USB.  1284.4 is an IEEE standard based on MLC.

> Many, many thanks to David for making this available.
You're quite welcome; I'm glad it's useful to you.  Thank you for your
interest and feedback.

David

RE: [hpoj-devel] new "ptal-mlcd" I/O driver checked into CVS

[PASCHAL,DAVID (HP-Roseville,ex1) <dav...@hp...>]

Joe Piolunek wrote:
> I'm using a RedHat 6.1 system, but I built the compiler (gcc 
> 2.95.2) from 
> source. The glibc version (2.1.3-22) is the redhat-supplied 
> rpm update that I 
> installed because of the reported security vulnerability in 
> earlier packages. 
> I wouldn't go back to an earlier version.
Good to know.  I suppose that reduces the exposure of this problem compared
to if this combination were provided out-of-the-box.  But don't worry; I'll
fix this one way or another.  I wouldn't want you to have to upgrade or
downgrade anything for this.  I don't think changing glibc would fix it
anyway, since probably all versions have the double colons that confuse the
C++ compiler you currently have installed.  Could you send your version of
sys/io.h to my non-HP address?  I'd like to diff it against what I have on
my system at home.

> My system doesn't seem to be broken. I've been building Qt 
> and KDE2 from 
> source, as well as many C-only apps.
I would expect that QT and KDE don't do any low-level I/O port access from
user space.  :-)

(regarding whether putting a space between the double colons fixes the
problem):
> I don't know. I didn't try it, though I will if I need to. 
> The comments I 
> found were from gcc, glibc or redhat development mailing 
> lists, so they may 
> not be useful advice for many other people.  
It would be helpful if you tried it in at least one place, just to see if it
makes the error in that place go away.  If so, then perhaps I could include
a "fixed" version as a workaround, although it might not be optimal to ship
__asm__ statements with a package I want to be as platform independent as
possible.  :-)

> I tried to compile a file containing the code below calling 
> both gcc and g++ 
> as the compiler. The filename ending was '.c' in both cases. 
> gcc had no 
> trouble compiling it, but when I attempted to compile it with 
> g++, it barfed 
> (possibly on the '::') causing the same errors I reported earlier.
> 
> If  the file is resaved with a .cpp suffix and gcc is called 
> to compile it, 
> it barfs.
> 
> 
> /*
> filename: test_including_io_h.c
> */
> #include </usr/include/sys/io.h>
> #include <stdio.h>
> 
> int main(){
>         printf("Hello World\n");
>         exit(0);
> }

Thanks for trying that.  Since it works in C, the cleanest workaround may be
to detect the problem in the configure script, and in that case compile in a
C wrapper that includes sys/io.h and re-exports the inb/outb functions.

David

[hpoj-devel] Scanning with T65

[Gerard H. P. <gh...@sk...>]

I'd just like to know if there is any hope left.

I was also wondering if I could be of any assistance, debugging or even
writing code myself, I've got some programming experience (23 years, 12+
in C).  I'm running a 2.4.2 SMP kernel.
-- 

Gerard H. Pille

Re: [hpoj-devel] new "ptal-mlcd" I/O driver checked into CVS

[Joe P. <joe...@sn...>]

On Monday 12 March 2001 03:12 am, David Paschal wrote:

> Remind me again which version of RedHat you're using?  Are these the stock
> versions of glibc and gcc that came with this version?

I'm using a RedHat 6.1 system, but I built the compiler (gcc 2.95.2) from 
source. The glibc version (2.1.3-22) is the redhat-supplied rpm update that I 
installed because of the reported security vulnerability in earlier packages. 
I wouldn't go back to an earlier version.

My system doesn't seem to be broken. I've been building Qt and KDE2 from 
source, as well as many C-only apps.


> > A suggested fix is to "change '::' to ' : : ' in
> > sys/io.h" .
>
> Does that work?  Of course, that isn't a proper solution, since I don't
> want people to have to hack system include files in order to build hpoj.

I don't know. I didn't try it, though I will if I need to. The comments I 
found were from gcc, glibc or redhat development mailing lists, so they may 
not be useful advice for many other people.  

>
> I'm wondering if this problem only affects C++ and not C code.  Could you
> please try writing a simple "hello world" program compiled as C (not C++),
> and include this file?  If it works OK for C code, then perhaps I could add
> a small C wrapper for the in/out functions to avoid including this file in
> a C++ file.  Of course, it wouldn't be good for performance, since those
> functions would no longer be inlined.


I tried to compile a file containing the code below calling both gcc and g++ 
as the compiler. The filename ending was '.c' in both cases. gcc had no 
trouble compiling it, but when I attempted to compile it with g++, it barfed 
(possibly on the '::') causing the same errors I reported earlier.

If  the file is resaved with a .cpp suffix and gcc is called to compile it, 
it barfs.


/*
filename: test_including_io_h.c
*/
#include </usr/include/sys/io.h>
#include <stdio.h>

int main(){
        printf("Hello World\n");
        exit(0);
}


Here is the output when attempting to compile the above code with g++.

]$ g++ -o test_including_io_h test_including_io_h.c
In file included from test_including_io_h.c:4:
/usr/include/sys/io.h: In function `void outb(unsigned char, short unsigned 
int)':
/usr/include/sys/io.h:98: parse error before `::'
/usr/include/sys/io.h: In function `void outb_p(unsigned char, short unsigned 
int)':
/usr/include/sys/io.h:104: parse error before `::'
/usr/include/sys/io.h: In function `void outw(short unsigned int, short 
unsigned int)':
/usr/include/sys/io.h:111: parse error before `::'
/usr/include/sys/io.h: In function `void outw_p(short unsigned int, short 
unsigned int)':
/usr/include/sys/io.h:118: parse error before `::'
/usr/include/sys/io.h: In function `void outl(unsigned int, short unsigned 
int)':
/usr/include/sys/io.h:125: parse error before `::'
/usr/include/sys/io.h: In function `void outl_p(unsigned int, short unsigned 
int)':
/usr/include/sys/io.h:131: parse error before `::'

-- 
Joe

[hpoj-devel] Success with G85

[Allen B. <ba...@lo...>]

I installed 0.8 of the OfficeJet drivers per the very detailed
instructions in the README files and have successfully scanned from, and
printed to, a G85 connected through its USB port.

This is my first scanner and color printer so I've got a couple of
newbie questions, if you don't mind.

It takes a relatively long time (~4.5 minutes) to scan at 600 dpi. The
head moves a little bit forward, then backs up a couple of times, then
goes a little bit further. Is this normal behavior? (Lower resolutions,
even 300 dpi, seem to zip right through). (Also, what's the best tool to
look at a 107Mb TIFF file :-)

The RedHat printtool test page shows the red hat logo and a set of
sample colors. The red in the "red hat" is a reasonably bright, however
the red in the sample color bar is much too dark. I guess this is a
gamma problem, but why would the two reds look so different? Presumably,
the red in the logo is from a PostScript bitmap and the red in the color
sample is just a filled rectangle. Is one gamma correction going to
affect both?

Finally, what does MLC stand for?

Many, many thanks to David for making this available.

Allen

Re: [hpoj-devel] SNMP dependency

[<pa...@rc...>]

James Klicman wrote:
> ptal-hpjd.c seems to have an SNMP dependency. Is it possible to compile
> without SNMP support?

Hi, James.  I just checked in a fix for this problem.  Run "cvs update" and
try it now.  Note that if you replaced ptal-hpjd.c with the version from 0.7,
then you should probably just delete that file and let "cvs update" replace
it with the lastest version.  If you don't then it might try to do a merge,
and you might not get what you want.

David

Re: [hpoj-devel] new "ptal-mlcd" I/O driver checked into CVS

[<pa...@rc...>]

Joe Piolunek wrote:
> Unfortunately, the error still occurs.
Bummer.  :-)

> A search for " /usr/include/sys/io.h:98: parse error before `::'" turned up a 
> few comments indicating that it may be related to a bug in gcc, which may be 
> fixed in ver. 2.96 . There was a report of the problem going away if using an 
> earlier version of glibc.
Remind me again which version of RedHat you're using?  Are these the stock
versions of glibc and gcc that came with this version?

> A suggested fix is to "change '::' to ' : : ' in 
> sys/io.h" .
Does that work?  Of course, that isn't a proper solution, since I don't want
people to have to hack system include files in order to build hpoj.

> I tried to use a #define ... #undef wrapper, but got errors about 
> using an improper macro name.
I'm not surprised that that doesn't work.  Generally #define only works with
symbols, not operators.

I'm wondering if this problem only affects C++ and not C code.  Could you
please try writing a simple "hello world" program compiled as C (not C++),
and include this file?  If it works OK for C code, then perhaps I could add
a small C wrapper for the in/out functions to avoid including this file in
a C++ file.  Of course, it wouldn't be good for performance, since those
functions would no longer be inlined.

David

Re: [hpoj-devel] SANE Drivers

[<pa...@rc...>]

Allen Barnett wrote:
> My ISP's DNS server can't seem to resolve www.mostang.com. Does anybody
> have an IP address for it? Or perhaps an alternate source for SANE
> 1.0.4?

Hi, Allen.  It seems that SANE's ISP changed their IP address, and the new
address is still probably trickling its way through the DNS servers, so for
now you can use the IP address (24.1.107.201).  The announcement from the
sane-devel mailing list is below.

David


> Date: Sat, 10 Mar 2001 10:47:21 -0800
> From: David Mosberger-Tang <Dav...@ac...>
> To: san...@mo...
> Subject: mostang.com back up
>
> If you tried to connect to www.mostang.com over the last day or so,
> you'll have noticed that it was disconnected.  It turns out my ISP
> assigned me a different IP address---without saying anything.  Just
> love it when they do that.
>
> Anyhow, the name server has been updated but it will take a couple of
> days to spread to all the name servers.  In the meantime, you should
> be able to connect by directly using the new IP address:
>
> 	www.mostang.com = 24.1.107.201
>
> Sorry for the inconvenience.
>
> 	--david 

[hpoj-devel] SANE Drivers

[Allen B. <ba...@lo...>]

My ISP's DNS server can't seem to resolve www.mostang.com. Does anybody
have an IP address for it? Or perhaps an alternate source for SANE
1.0.4?

Thanks,
Allen

Re: [hpoj-devel] new "ptal-mlcd" I/O driver checked into CVS

[Joe P. <joe...@sn...>]

On Saturday 10 March 2001 11:00 pm, David Paschal wrote:

> > /usr/include/sys/io.h:98: parse error before `::'
>
> Hi, Joe.  Thanks for the bug report.  I just checked in a change to
> ParPort.h to wrap "#include <sys/io.h>" with 'extern "C" { }'.  Try it
> again after doing a "cvs update" and see if that fixes the problem. 
> Perhaps I should go through and do this around most if not all #includes
> from C++ files, just to be on the safe side.
>

Unfortunately, the error still occurs.

A search for " /usr/include/sys/io.h:98: parse error before `::'" turned up a 
few comments indicating that it may be related to a bug in gcc, which may be 
fixed in ver. 2.96 . There was a report of the problem going away if using an 
earlier version of glibc. A suggested fix is to "change '::' to ' : : ' in 
sys/io.h" . I tried to use a #define ... #undef wrapper, but got errors about 
using an improper macro name.

-- 
Joe

Re: [hpoj-devel] SNMP dependency

[<pa...@rc...>]

James Klicman wrote:
> ptal-hpjd.c seems to have an SNMP dependency. Is it possible to compile
> without SNMP support?

Hi, James.  Sorry about that.  I should have tested building with all possible
combiniations of packages before checking in those changes.  I'll make sure
and fix that ASAP, but in the meantime, I think you can get by if you just
replace ptal-hpjd.c with the version from 0.7.

David

[hpoj-devel] SNMP dependency

[James K. <ja...@me...>]

Hi David,

ptal-hpjd.c seems to have an SNMP dependency. Is it possible to compile
without SNMP support?

Thanks,

-James

$ make
ptal
make[1]: Entering directory `/net/sourceforge/hpoj/ptal'
cc -O -Wall -g  -I/net/sourceforge/hpoj/include -I/usr/lib/qt-2.2.1/include -L/net/sourceforge/hpoj/ptal -L/usr/lib/qt-2.2.1/lib -fPIC -c -o ptal.o-shared ptal.c
ptal.c: In function `ptalPmlRequestSetTrap':
ptal.c:1293: warning: control reaches end of non-void function
cc -O -Wall -g  -I/net/sourceforge/hpoj/include -I/usr/lib/qt-2.2.1/include -L/net/sourceforge/hpoj/ptal -L/usr/lib/qt-2.2.1/lib -fPIC -c -o ptal-hpjd.o-shared ptal-hpjd.c
ptal-hpjd.c: In function `ptalHpjdDeviceGetDeviceIDString':
ptal-hpjd.c:271: warning: unused variable `dev'
ptal-hpjd.c: At top level:
ptal-hpjd.c:547: parse error before `ptalHpjdSnmpOidPml'
ptal-hpjd.c:547: warning: type defaults to `int' in declaration of `ptalHpjdSnmpOidPml'
ptal-hpjd.c:547: warning: data definition has no type or storage class
ptal-hpjd.c:548: parse error before `ptalHpjdSnmpOidDeviceID'
ptal-hpjd.c:548: warning: type defaults to `int' in declaration of `ptalHpjdSnmpOidDeviceID'
ptal-hpjd.c:548: warning: data definition has no type or storage class
ptal-hpjd.c:549: parse error before `ptalHpjdSnmpOidNumPorts'
ptal-hpjd.c:549: warning: type defaults to `int' in declaration of `ptalHpjdSnmpOidNumPorts'
ptal-hpjd.c:549: warning: data definition has no type or storage class
ptal-hpjd.c:551: parse error before `oid'
ptal-hpjd.c: In function `ptalHpjdPmlToSnmpOid':
ptal-hpjd.c:552: `obj' undeclared (first use in this function)
ptal-hpjd.c:552: (Each undeclared identifier is reported only once
ptal-hpjd.c:552: for each function it appears in.)
ptal-hpjd.c:553: `oid' undeclared (first use in this function)
ptal-hpjd.c:556: `snmpOid' undeclared (first use in this function)
ptal-hpjd.c:560: `MAX_OID_LEN' undeclared (first use in this function)
ptal-hpjd.c: At top level:
ptal-hpjd.c:567: parse error before `oid'
ptal-hpjd.c: In function `ptalHpjdPmlFromSnmpOid':
ptal-hpjd.c:569: `oid' undeclared (first use in this function)
ptal-hpjd.c:571: `snmpOidLen' undeclared (first use in this function)
ptal-hpjd.c:572: `snmpOid' undeclared (first use in this function)
ptal-hpjd.c:582: `obj' undeclared (first use in this function)
ptal-hpjd.c: In function `ptalHpjdPmlGet':
ptal-hpjd.c:611: `SNMP_MSG_GETNEXT' undeclared (first use in this function)
ptal-hpjd.c:611: `SNMP_MSG_GET' undeclared (first use in this function)
ptal-hpjd.c:614: `oid' undeclared (first use in this function)
ptal-hpjd.c:614: parse error before `name'
ptal-hpjd.c:621: warning: implicit declaration of function `snmp_pdu_create'
ptal-hpjd.c:621: warning: assignment makes pointer from integer without a cast
ptal-hpjd.c:625: `name' undeclared (first use in this function)
ptal-hpjd.c:631: warning: implicit declaration of function `snmp_add_null_var'
ptal-hpjd.c:633: warning: implicit declaration of function `snmp_synch_response'ptal-hpjd.c:633: structure has no member named `snmpSession'
ptal-hpjd.c:634: `STAT_SUCCESS' undeclared (first use in this function)
ptal-hpjd.c:635: warning: implicit declaration of function `snmp_error'
ptal-hpjd.c:635: structure has no member named `snmpSession'
ptal-hpjd.c:644: dereferencing pointer to incomplete type
ptal-hpjd.c:644: `SNMP_ERR_NOERROR' undeclared (first use in this function)
ptal-hpjd.c:648: dereferencing pointer to incomplete type
ptal-hpjd.c:648: warning: implicit declaration of function `snmp_errstring'
ptal-hpjd.c:648: dereferencing pointer to incomplete type
ptal-hpjd.c:652: dereferencing pointer to incomplete type
ptal-hpjd.c:656: dereferencing pointer to incomplete type
ptal-hpjd.c:656: dereferencing pointer to incomplete type
ptal-hpjd.c:659: dereferencing pointer to incomplete type
ptal-hpjd.c:668: `ASN_INTEGER' undeclared (first use in this function)
ptal-hpjd.c:673: dereferencing pointer to incomplete type
ptal-hpjd.c:674: break statement not within loop or switch
ptal-hpjd.c:676: `ASN_OCTET_STR' undeclared (first use in this function)
ptal-hpjd.c:678: dereferencing pointer to incomplete type
ptal-hpjd.c:680: dereferencing pointer to incomplete type
ptal-hpjd.c:685: break statement not within loop or switch
ptal-hpjd.c:687: `ASN_NULL' undeclared (first use in this function)
ptal-hpjd.c:690: break statement not within loop or switch
ptal-hpjd.c:705: default label not within a switch statement
ptal-hpjd.c:708: dereferencing pointer to incomplete type
ptal-hpjd.c:716: warning: implicit declaration of function `snmp_free_pdu'
ptal-hpjd.c: In function `ptalHpjdPmlSet':
ptal-hpjd.c:729: `oid' undeclared (first use in this function)
ptal-hpjd.c:729: parse error before `name'
ptal-hpjd.c:736: `SNMP_MSG_SET' undeclared (first use in this function)
ptal-hpjd.c:736: warning: assignment makes pointer from integer without a cast
ptal-hpjd.c:740: `name' undeclared (first use in this function)
ptal-hpjd.c:743: `ASN_INTEGER' undeclared (first use in this function)
ptal-hpjd.c:748: `ASN_OCTET_STR' undeclared (first use in this function)
ptal-hpjd.c:751: warning: implicit declaration of function `snmp_pdu_add_variable'
ptal-hpjd.c:753: structure has no member named `snmpSession'
ptal-hpjd.c:754: `STAT_SUCCESS' undeclared (first use in this function)
ptal-hpjd.c:755: structure has no member named `snmpSession'
ptal-hpjd.c:762: dereferencing pointer to incomplete type
ptal-hpjd.c:762: `SNMP_ERR_NOERROR' undeclared (first use in this function)
ptal-hpjd.c:765: dereferencing pointer to incomplete type
ptal-hpjd.c:765: dereferencing pointer to incomplete type
make[1]: *** [ptal-hpjd.o-shared] Error 1
make[1]: Leaving directory `/net/sourceforge/hpoj/ptal'
make: *** [all] Error 2