hpoj-devel — HPOJ development/support list

RE: [hpoj-devel] Revised "gamma.ps info" + screenshot

[Salkind, L. <Lou...@de...>]

I finally got to install 0.6 last night.  RedHat 6.2 / Officejet 720.
Everything installed perfectly.

To test the colors, I started applying various gamma corrections as
suggested by Joe.  The good news is that the colors are much better than
they used to be.  I suspect this has a lot to do with the fact that I
installed a new ink cartridge before testing, but also because I have
slightly different parameters to cdj550.

Like Joe, I found that gamma.ps was needed.  Following the instructions on
http://graphics.stanford.edu/~ericv/gamma/gamma.html, I determined that the
best gamma for the OfficeJet 720 was about 1 / .475.  In other words,
instead of using .333 as Joe did, I used .475 instead.

The colors were still a bit off, though.  In particular, the blue, cyan, and
pink all looked a bit dark and possibly not quite the right color on a test
color strip (the Redhat print page).  I'm pretty sure gamma isn't helping
here, because the colors are being requested to be displayed at full
intensity.  What is needed is a slightly more sophisticated transformation.

Being curious, I tracked down some more web references and learned a bit
more about gamma, color management, etc.  If other (non-color experts) are
curious, I found the Charles Poynton FAQs to have a wealth of information:

http://www.inforamp.net/~poynton/GammaFAQ.html
http://www.inforamp.net/~poynton/ColorFAQ.html

I also found several web papers on how people in practice get the colors
right, e.g.

http://www-ise.stanford.edu/class/psych221/00/ben/
http://www.tsi.enst.fr/~hardeber/work/CIC1996_faxcolor/node5.html
the gimp manual, chapter 14

To make a long story short, it seems as though the procedure for calibrating
a printer/scanner device as follows:

a) obtain a high quality hard-copy print of known colors
b) scan these colors in with the scanner and compare the colors we think we
got to what we were expecting
c) compute the transformation function f required to normalize the scanner
input
d) print out a known test pattern on the printer
e) rescan in the test pattern and compare what we got to what we were
expecting
f) compute the transformation function h = g(f)   required to normalize the
combination of the scanned printed image input
g) compute the transformation function g = h(inverse(f)) to get the
correction to apply in the postscript file

I'm now tracking down references on what people typically use for the form
of these transformation functions.  It seems as though the colors are
transformed from either RGB or CMYK to CIE, which corresponds in a more
linear way to how humans can differentiate colors.  Then, a non-linear least
squres regression is applied to get the best fit between the input colors
and the measured colors.

I'm actually game to try this type of procedure some time once the scanning
support for the 720 is in place.  In the meantime, though, I'll live with
slightly weird color printing.

Lou

-----Original Message-----
From: pa...@rc... [mailto:pa...@rc...]
Sent: Tuesday, September 19, 2000 5:33 AM
To: hpo...@li...
Cc: pa...@rc...
Subject: Re: [hpoj-devel] Revised "gamma.ps info" + screenshot 


> I'm attaching a text file that contains a revised and augmented version o=
> f  the
> "gamma.ps info" that I posted earlier to the hpoj-devel mailing list. It =
> needed
> a little correction and more information. Please add to your docs if you =
> choose.
Hi, Joe.  Thank you very much for the updated information.  I will see about
putting it into a future version of the software.  Lou, does this updated
information help you any?

> According to your hpoj "TODO" list you are planning to expand the xojpane=
> l app.
> I don't really know how much functionality the hpoj project will eventual=
> ly
> have, but I'm assuming that some day there might be a need for a GUI.
> 
> Needing something new to learn, I slapped together the beginning of a Qt =
> -
> based GUI that could serve as a main window for a "hpoj control" front en=
> d. It
> builds and runs with no problems. It was done with the new Qt designer an=
> d
> Gimp.=20
Thanks for putting this together.  That's a really cute picture!  However,
a printer with its tongue sticking out isn't quite the emotion I wanted to
convey here.  :-)

I haven't done a lot of serious thinking on the matter yet, but basically
my vision was to have a list of attached devices (which would probably be
only one for most people, but many for me:-) on the left side (for example,
mlc:mlcpp0, hpjd:my-jdex.my-domain.com:1, etc.), and when you clicked on
one you would get a bunch of tabbed dialog boxes in the remainder of the
window, which would provide various status information and control options
for the selected device.  To list some possibilities by tab:
- general -- device's model name and number, and a summary of its
capabilities
(print, scan, fax send, fax receive, copy, etc.).  An option to test
communication with the device (via the MLC echo channel).
- status -- LCD contents (if available), and other general status info that
can be gathered via PML (online, offline, errors, etc.).
- print -- ink/toner levels, buttons to print various test pages and
initiate print cartridge alignment and cleaning operations.
- print queue -- to check on status of lpd print queue, cancel jobs, etc.
- scan -- buttons to launch various SANE frontends (xscanimage, xsane),
since there's no reason to re-invent the wheel.
- copy -- set options (copy count, color/b&w, image enhancement, special
features), start copy button.  Maybe options to assist the user with
advanced copying operations, such as double-sided copying.  Maybe somehow
take advantage of a duplex unit on the G series (if installed).
- fax configuration -- numerous options here (local phone number and station
name, dial-out access code, beep and volume options, country, blacklist
management, flash/line type, ring/answer/redial/forward options, dial mode,
speed dials, fax send/receive modes, etc.).
- fax status -- view/clear fax log of device and/or system.  Presumably
fax send/receive would be handled externally.  Fax send could be handled
by lpd queues, and fax receive could be done either manually from SANE
or automatically from some daemon, which could e-mail you the fax images.
- maybe some "geek options", for example to play around with PML: probe for
supported PML objects and display current values, get/set specific PML
objects, etc.

Did I say I haven't thought about this very much?  :-)  In any case, this
is a lot of functionality, and it would be a good idea to start small.
I also still need to try to get specs on some things, like how to determine
ink/toner levels and clean/align cartridges.

Does anyone have ideas to add to this wishlist for xojpanel-on-steroids?

David

_______________________________________________
hpoj-devel mailing list
hpo...@li...
http://lists.sourceforge.net/mailman/listinfo/hpoj-devel

RE: [hpoj-devel] New screenshot

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

Hi, Joe.  Thanks for putting together the new prototype so quickly.  It's
very close to what I had in mind.  One comment I'll make right now is that
we shouldn't restrict phone numbers to the US-style format of 3-digit area
code and 3+4-digit phone number.  I'd like this software to have world-wide
appeal, but of course that would also require translation capability, which
opens another whole can of worms.  :-)

> It already seems like a bigger project than I imagined it would be. It
> probably wouldn't take long to put together a dialog with 
> most of the things you
> mentioned, but I'm not a professional at this, so If there is 
> an experienced
> GUI designer involved in the project, that certainly would be 
> the person to do
> it.
Before anybody spends too much time on this I probably need to finish my
current project of adding PML support to PTAL, because that would provide
the necessary application-level infrastructure to support an application
like this.  Then it would probably be a good idea to write some simple
command-line scripts that play around with the various settings that are
available via PML so that we can better understand the functionality we're
trying to expose to the user.

PML multiplexing will also be important to have eventually so multiple
applications (such as SANE and xojpanel) can access PML concurrently.  I'm
looking into this too.

> If there isn't one available, I'm willing to help with 
> whatever I can. At the
> moment that would be limited to drag-and-drop *.ui creation and
> auto-generating a  *.cpp and *.h file from each *.ui, a 
> project file and Makefile.
> That is actually all done easily with the autogeneration 
> tools. Someone with
> strong c++ coding skills would need to do the actual 
> implementation afterwards.
I'm sure the prototypes you've done recently are good practice for you, so
feel free to practice and develop your skills all you want.  :-)

Damcha wrote:
> About xojpanel:	If you want, I can develop a GTK (GNOME 
> ?) version 
> of xojpanel. 
> Up to you...

And back to Joe:
> If you decide to use gtk instead of Qt, maybe Qt-generated 
> files or previews
> could still be used as a rough guide. 

I would welcome anybody who wants to come forward and help develop and
maintain such a program, and either GTK or QT would be fine with me.  If I
were doing it myself I would probably use QT and QT Designer, but that's
just my personal preference and I don't want to start a QT vs GTK or KDE vs
GNOME flame war.  That said, I would still prefer that there not be wasted
effort in developing two separate versions using different GUI toolkits.

David

RE: [hpoj-devel] SMP Problems && ojpanel-on-steroids

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

> As I said before, if I may be helpful, I'll do it...
> 
> For the SMP problem :   1- I don't have a lot of experience 
> about kernel 
> programming or SMP locking		 BUT
> 				2.1- I'd really like to learn both
> 			AND	2.2- I've got an SMP system 
> with a 2.4 kernel 
> 			AND	2.3- I study SMP at school 
> (began yesterday)
> 			so I think I should be efficient quite 
> quickly...

Hi, Damcha.  Sorry, I forgot you had indicated an interest in working on
this.  The kernel driver code is begging for a better maintainer than me, so
thanks for volunteering.  :-)  Burkhard also indicated an interest in this,
but it sounds like you're more SMP-equipped than he is.  Anyway, I'll let
the two of you decide how you want to go about working on this, and perhaps
Gerhard can provide some technical guidance from time to time as well.  I
shall look forward to your patches.  :-)

David

[hpoj-devel] New screenshot

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

On Tue, 19 Sep 2000, David Paschal wrote:
<...>
> Thanks for putting this together.  That's a really cute picture!  However,
> a printer with its tongue sticking out isn't quite the emotion I wanted to
> convey here.  :-)
>

But many officejets _do_ have a big tongue sticking out to catch the paper!
I agree though, that this graphic isn't appropriate for the serious business
app that you seem to be planning. For home users, some graphics would be
nice. If skin support were added some day, stranger things than this could find
their way onto the main window.

 > I haven't done a lot of serious thinking on the matter yet, but basically
> my vision was to have a list of attached devices (which would probably be
> only one for most people, but many for me:-) on the left side (for example,
> mlc:mlcpp0, hpjd:my-jdex.my-domain.com:1, etc.), and when you clicked on
> one you would get a bunch of tabbed dialog boxes in the remainder of the
> window, which would provide various status information and control options
> for the selected device.  To list some possibilities by tab:

< much deletion here>
 
> Did I say I haven't thought about this very much?  :-)  In any case, this
> is a lot of functionality, and it would be a good idea to start small.
> I also still need to try to get specs on some things, like how to determine
> ink/toner levels and clean/align cartridges.
> 
> Does anyone have ideas to add to this wishlist for xojpanel-on-steroids?
> 
> David
> 


It already seems like a bigger project than I imagined it would be. It
probably wouldn't take long to put together a dialog with most of the things you
mentioned, but I'm not a professional at this, so If there is an experienced
GUI designer involved in the project, that certainly would be the person to do
it.

If there isn't one available, I'm willing to help with whatever I can. At the
moment that would be limited to drag-and-drop *.ui creation and
auto-generating a  *.cpp and *.h file from each *.ui, a project file and Makefile.
That is actually all done easily with the autogeneration tools. Someone with
strong c++ coding skills would need to do the actual implementation afterwards.

If you decide to use gtk instead of Qt, maybe Qt-generated files or previews
could still be used as a rough guide. 

I have a new screenshot available at

http://pages.cthome.net/jsp/hpoj-linux-gui/hpoj-gui.html

It looks more like what you described. This one is only a designer preview.

---------
Joe

Re: [hpoj-devel] kernel drivers broken with SMP

[Burkhard K. <bu...@bu...>]

From: Burkhard Kohl <bu...@bu...>
Message-Id: <200...@bu...>
Subject: Re: [hpoj-devel] kernel drivers broken with SMP
In-Reply-To: <200009180732.AAA13385@axel.local> from David Paschal at "Sep 18,
	2000 00:32:56 am"
To: hpo...@li... 
Date: Tue, 19 Sep 2000 20:39:54 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL60 (25)]

David Paschal
> Hi, Gerhard and Burkhard.  Thanks for providing the information regarding
> the SMP and 2.4-kernel problems, which seem to be interrelated.  You seem
> to have a much better understanding of kernel issues than I do.  If either
> or both of you would be willing to work towards a solution to these problems,
> that would be greatly appreciated, and would leave me more time to develop
> scanning support for the scrollfed MFPs, which I started working on last week.
> :-)
> 
I started to work on the SMP/2.4 issues - might take some time, since
I can do this only in my spare time. But I have to point out that I 
have no SMP system to test on and that I am less than familiar with 
the locking necessities of socket related issues. And I am not what 
would be called a *real* kernel hacker.

> ger...@mc... said:
> > 1. A driver, that has been compiled for an UP kernel cannot be used
> > with
> >    an SMP kernel (and vice versa).
> >    An SMP module must be compiled using kernel header files
> >    which are configured for SMP (-> CONFIG_SMP) and with the
> >    compiler flag -D__SMP__
> 
> >    Is the current Makefile prepared to compile either SMP or UP
> > modules? 
> Good point.  Currently, ieee12844/Makefile.in starts with the following lines:
> 	SMP=
> 	# SMP=-D__SMP__
> 
> 	CFLAGS = -O @INCLUDE_CMDLINE@ -Wall -Wstrict-prototypes -D__KERNEL__ \
> 		 -DMODULE -DEXPORT_SYMTAB $(SMP)
> As it stands now, the __SMP__ symbol is not passed to kernel includes.
> So, Alexander, one thing you could try is uncommenting out the second line.
> If you modify Makefile, then you can recompile right away but the change
> will be lost the next time you run the ./configure script.  If you modify
> Makefile.in, then you will need to re-run ./configure before you try
> recompiling.  Since this problem appears in all versions, you might as well
> use the latest (0.6).
This could be cured by looking at CONFIG_SMP from <linux/config.h> and 
defining __SMP__ accordingly before inclusion of any other header
files. I can take care of that.

If anyone wants to compile an SMP-module although the kernel is
configured non-SMP and vice versa, he/she has to edit the Makefile.

Burkhard
-- 
Burkhard Kohl			bu...@bu...

[hpoj-devel] SMP Problems && ojpanel-on-steroids

[Damcha <da...@cy...>]

Hello,

As I said before, if I may be helpful, I'll do it...

For the SMP problem :   1- I don't have a lot of experience about kernel 
programming or SMP locking		 BUT
				2.1- I'd really like to learn both
			AND	2.2- I've got an SMP system with a 2.4 kernel 
			AND	2.3- I study SMP at school (began yesterday)
			so I think I should be efficient quite quickly...

About xojpanel:	If you want, I can develop a GTK (GNOME ?) version 
of xojpanel. 
Up to you...

Damcha

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d--(+) s: a-- C++ UL+++ P+>++ L+++ E(+) W++ N+ o? K- w-- O? M V?
PS++ PE- Y+ PGP t+ 5 X++ R(+) tv-(+) b+ DI D++ G e+++ h--- r++ y+++*
------END GEEK CODE BLOCK------
					 See http://www.geekcode.com

Re: [hpoj-devel] Re: SMP Problems with hpoj-0.6

[Gerhard <ger...@fu...>]

cc...@va... wrote:
> 
> > Does using the "nosmp" parameter on an SMP-enabled kernel and SMP system, or
> > using an SMP-enabled kernel on a non-SMP system make the problem go away?
> > If so, then I won't be able to work on this, since I don't have any SMP
> > systems.
> 
> SMP system with SMP enabled in kernel causes lockups.
> SMP system with SMP disabled in kernel, lockups go away.
> 
> ccb

As expected ...
As I already noted earlier, our drivers currently aren't SMP-capable. We
definitely should fix this and should revise the locking stuff which also has
changed in recent kernel version. This changes should also be done in a way,
that the modules work with all (2.2, 2.3 and 2.4) kernels.
Any volounteers to do it?

Thanks,
Gerhard

Re: [hpoj-devel] Re: SMP Problems with hpoj-0.6

[<cc...@va...>]

> Does using the "nosmp" parameter on an SMP-enabled kernel and SMP system, or
> using an SMP-enabled kernel on a non-SMP system make the problem go away?
> If so, then I won't be able to work on this, since I don't have any SMP
> systems.

SMP system with SMP enabled in kernel causes lockups.
SMP system with SMP disabled in kernel, lockups go away.

ccb



--
Charles C. Bennett, Jr.			VA Linux Systems
Systems Engineer,			25 Burlington Mall Rd., Suite 300
US Northeast Region			Burlington, MA 01803-4145
+1 617 543-6513				+1 888-LINUX-4U
cc...@va...				www.valinux.com
 vi/(emacs)  NT/(Linux)  qmail/(sendmail)  (perl)/python  (pepsi)/coke

Re: [hpoj-devel] Revised "gamma.ps info" + screenshot

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

> I'm attaching a text file that contains a revised and augmented version o=
> f  the
> "gamma.ps info" that I posted earlier to the hpoj-devel mailing list. It =
> needed
> a little correction and more information. Please add to your docs if you =
> choose.
Hi, Joe.  Thank you very much for the updated information.  I will see about
putting it into a future version of the software.  Lou, does this updated
information help you any?

> According to your hpoj "TODO" list you are planning to expand the xojpane=
> l app.
> I don't really know how much functionality the hpoj project will eventual=
> ly
> have, but I'm assuming that some day there might be a need for a GUI.
> 
> Needing something new to learn, I slapped together the beginning of a Qt =
> -
> based GUI that could serve as a main window for a "hpoj control" front en=
> d. It
> builds and runs with no problems. It was done with the new Qt designer an=
> d
> Gimp.=20
Thanks for putting this together.  That's a really cute picture!  However,
a printer with its tongue sticking out isn't quite the emotion I wanted to
convey here.  :-)

I haven't done a lot of serious thinking on the matter yet, but basically
my vision was to have a list of attached devices (which would probably be
only one for most people, but many for me:-) on the left side (for example,
mlc:mlcpp0, hpjd:my-jdex.my-domain.com:1, etc.), and when you clicked on
one you would get a bunch of tabbed dialog boxes in the remainder of the
window, which would provide various status information and control options
for the selected device.  To list some possibilities by tab:
- general -- device's model name and number, and a summary of its capabilities
(print, scan, fax send, fax receive, copy, etc.).  An option to test
communication with the device (via the MLC echo channel).
- status -- LCD contents (if available), and other general status info that
can be gathered via PML (online, offline, errors, etc.).
- print -- ink/toner levels, buttons to print various test pages and
initiate print cartridge alignment and cleaning operations.
- print queue -- to check on status of lpd print queue, cancel jobs, etc.
- scan -- buttons to launch various SANE frontends (xscanimage, xsane),
since there's no reason to re-invent the wheel.
- copy -- set options (copy count, color/b&w, image enhancement, special
features), start copy button.  Maybe options to assist the user with
advanced copying operations, such as double-sided copying.  Maybe somehow
take advantage of a duplex unit on the G series (if installed).
- fax configuration -- numerous options here (local phone number and station
name, dial-out access code, beep and volume options, country, blacklist
management, flash/line type, ring/answer/redial/forward options, dial mode,
speed dials, fax send/receive modes, etc.).
- fax status -- view/clear fax log of device and/or system.  Presumably
fax send/receive would be handled externally.  Fax send could be handled
by lpd queues, and fax receive could be done either manually from SANE
or automatically from some daemon, which could e-mail you the fax images.
- maybe some "geek options", for example to play around with PML: probe for
supported PML objects and display current values, get/set specific PML
objects, etc.

Did I say I haven't thought about this very much?  :-)  In any case, this
is a lot of functionality, and it would be a good idea to start small.
I also still need to try to get specs on some things, like how to determine
ink/toner levels and clean/align cartridges.

Does anyone have ideas to add to this wishlist for xojpanel-on-steroids?

David

[hpoj-devel] Revised "gamma.ps info" + screenshot

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

David -

I'm attaching a text file that contains a revised and augmented version o=
f  the
"gamma.ps info" that I posted earlier to the hpoj-devel mailing list. It =
needed
a little correction and more information. Please add to your docs if you =
choose.

On a different subject - =20

According to your hpoj "TODO" list you are planning to expand the xojpane=
l app.
I don't really know how much functionality the hpoj project will eventual=
ly
have, but I'm assuming that some day there might be a need for a GUI.

Needing something new to learn, I slapped together the beginning of a Qt =
-
based GUI that could serve as a main window for a "hpoj control" front en=
d. It
builds and runs with no problems. It was done with the new Qt designer an=
d
Gimp.=20

My coding ability is sparse, so I haven't been able to add any real
functionality to it yet. It would need someone else to do the implementat=
ion
if it were used for a project like hpoj. Still, it may be  worth your loo=
king
at it.

A screenshot of the running app is here:

http://pages.cthome.net/jsp/hpojc/hpojc_mw.jpg

--=20
Joe Piolunek =20
                                      =20

Re: [hpoj-devel] Library Problems with install

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

Hi, Sammy.

> H ave unziped the hpoj-0.6 tarball sucessfully and i get through the ./configure
> and and make command  then i get to make install and it keep saying  add
> usr/local/lib to /etc/ld.so.conf which I did  i then ran idconfig tried again and
> get the same error
When you invoke "make install", the message telling you to add /usr/local/lib
to /etc/ld.so.conf and run "ldconfig" is simply a reminder of the next step
in the installation process, not an error.  Once you've done this next step
(which it sounds like you have), you can verify that it works by saying
"ldd /usr/local/bin/ptal-connect".  You should see a line like:
	libptal.so.0 => /usr/local/lib/libptal.so.0 (0x40015000)
The number in parentheses may be different.  On the other hand, if this line
says something like "not found", then something's wrong.

> then i try idconfig-D it say about 50 files have inconsistant
> soname there to many to list
Strange.  "ldconfig -D" reports many of the same errors on my system too.
I don't think it's anything to worry about, though.  I've never used the
-D switch, though.  When I want to verify things after running "ldconfig",
I normally run "ldconfig -p".

> and do not know how to  copy the text of Konsole to
> put into the email.
I don't think it's necessary here, but for future reference, the basic
procedure is to move the mouse to the start of the text you want to copy,
hold down the left button while you drag the mouse to the end of the text,
and release the button.  Then move the mouse to where you want to paste the
text, and click the middle button once.  If your mouse has two buttons
instead of three, then you can simulate the middle button by pressing both
buttons at the same time, if your X server is configured properly.

> I am wondering if anyone knows what going on with my library files and how to fix
> it for my distro which is mandrake 7on a 2.2-14 kernal . I have managed to get
> the modules to load  but need the source code complied before i can go any
> further and i have no idea how to do this.
It sounds to me like you've done everything correctly so far.  If you haven't
already, you can now proceed with the "SCAN-HOWTO" file so that you can
finally scan on your 1150C.  Let me know how that goes.  :-)

David

Re: [hpoj-devel] Library Problems with install

[Sammy R. <re...@ca...>]

H ave unziped the hpoj-0.6 tarball sucessfully and i get through the ./configure
and and make command  then i get to make install and it keep saying  add
usr/local/lib to /etc/ld.so.conf which I did  i then ran idconfig tried again and
get the same error then i try idconfig-D it say about 50 files have inconsistant
soname there to many to list and do not know how to  copy the text of Konsole to
put into the email.
I am wondering if anyone knows what going on with my library files and how to fix
it for my distro which is mandrake 7on a 2.2-14 kernal . I have managed to get
the modules to load  but need the source code complied before i can go any
further and i have no idea how to do this.

I would be greatful for your help

Sammy

Re: [hpoj-devel] kernel drivers broken with SMP

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

Hi, Gerhard and Burkhard.  Thanks for providing the information regarding
the SMP and 2.4-kernel problems, which seem to be interrelated.  You seem
to have a much better understanding of kernel issues than I do.  If either
or both of you would be willing to work towards a solution to these problems,
that would be greatly appreciated, and would leave me more time to develop
scanning support for the scrollfed MFPs, which I started working on last week.
:-)

ger...@mc... said:
> 1. A driver, that has been compiled for an UP kernel cannot be used
> with
>    an SMP kernel (and vice versa).
>    An SMP module must be compiled using kernel header files
>    which are configured for SMP (-> CONFIG_SMP) and with the
>    compiler flag -D__SMP__

>    Is the current Makefile prepared to compile either SMP or UP
> modules? 
Good point.  Currently, ieee12844/Makefile.in starts with the following lines:
	SMP=
	# SMP=-D__SMP__

	CFLAGS = -O @INCLUDE_CMDLINE@ -Wall -Wstrict-prototypes -D__KERNEL__ \
		 -DMODULE -DEXPORT_SYMTAB $(SMP)
As it stands now, the __SMP__ symbol is not passed to kernel includes.
So, Alexander, one thing you could try is uncommenting out the second line.
If you modify Makefile, then you can recompile right away but the change
will be lost the next time you run the ./configure script.  If you modify
Makefile.in, then you will need to re-run ./configure before you try
recompiling.  Since this problem appears in all versions, you might as well
use the latest (0.6).

Many thanks also to Damcha and Alexander for reporting these problems and
bearing with us as they hopefully get fixed.

For the longer term, I'm exploring options to replace as much as possible
of the kernel-mode drivers with a user-mode daemon that continues to support
MLC and parallel as today and adds support for 1284.4 and USB.  The low-level
interfaces to this daemon would be Unix-domain sockets, so it would have
similar semantics to the AF_MLC sockets used today.  A user-mode approach
would provide better stability, maintainability, and portability due to less
dependence on the Linux kernel interfaces.  But I don't have any definite
plans as of yet, so it would still be good to press on with resolving these
problems with the current code.

BTW, I changed the hpoj-devel mailing list so replies are sent to the list,
the way it was with bstc.net.  Therefore, it's no longer necessary to
"reply to all" to direct replies to the list.  I hope nobody will be upset
by this change.

David

Re: [hpoj-devel] kernel drivers broken with SMP

[Burkhard K. <bu...@bu...>]

Gerhard Fuernkranz
> Gerhard Fuernkranz wrote:
> > 
> >    There is one more thing, which gives me a strange feeling in my stomach,
> >    and that's the fact, that somebody had reported that start_bh_atomic()
> >    and friends do no longer exist in newer 2.3 kernels. Actually I had used
> >    them to prevent races between the top and bottom halves - so I've no
> >    idea what will happen, if they are just skipped.
> 
> After a very short look at the current SuSE 6.4 (-> 2.2.14) sources it
> appears, that ret_from_intr in entry.S does *NOT* run the bottom halfes -
> except it reschedules the current process (in this case schedule() runs them).
> But as long as the top half is running in the kernel, the process should not
> be rescheduled. Therefore I think, that an interrupt should not be able
> trigger a bottom half handler, which can interrupt the top half running in
> kernel mode (-> in an UP(!!!) kernel). But I've taken only a very short look
> and I could have overlooked something ...
> 
> So IMHO there is a chance, that explicit locking between the top and bottom
> halfes is no longer required (for UP kernels) and is just a relict which was
> required in some older kernel version (maybe 2.0???). I cannot remember ...
> Probably they also have removed start_bh_atomic() and friends from recent 2.3
> kernels, because it is no longer required? (in UP kernels and SMP kernels need
> different locking methods anyway).

There is a guide for kernel-locking issues - the kernel-locking-HOWTO. 
It use to be on http://netfilter.kernelnotes.org/unreliable-guides
but seems to be vanished from there. I found it mirrored on 
	pusa.uv.es/~ulisses/netfilter.kernelnotes.org/unreliable-guides

> 
> Nevertheless all the locking stuff in the drivers should be investigated very
> carefully, especially SMP locking, which is currently definitely not supported
> (i.e. missing) in ieee*.c.
> E.g. if the start_bh_atomic() go away, then there are no locks at all, which
> will prevent a top half from running on one processor while a bottom half is
> running on a different processor simultaneouly. So spinlocks must be added to
> protect critical regions in order to handle such situations properly.
The issue of BH is described in Chapter 7. Essentially BH are now 
deprecated due to their limitations with respect to SMP. From a quick 
glance I learned that BH were reimplemented underneath softirqs. There
are now spinlock primitives for "BHs": spin_lock_bh() and spin_unlock_bh().
Other primitives exist: spin_lock_irq, read_lock_irq/bh, write_lock_irq/bh
and their counterparts. For non-SMP systems they collapse to a 
local_xx_disable() call.

If I compare the slip driver from 2.2.14 to 2.4.0 I see that calls to
start_bh_atomic have been replaced by spin_lock_bh. I have to apologize
for not noting this in my former posting where I had only grepped for 
bh_atomic and found some pieces of code where it had vanished without 
replacement.

Burkhard

-- 
Burkhard Kohl	buk at/auf buks.ipn.de

Re: [hpoj-devel] kernel drivers broken with SMP

[Gerhard F. <ger...@mc...>]

Gerhard Fuernkranz wrote:
> 
>    There is one more thing, which gives me a strange feeling in my stomach,
>    and that's the fact, that somebody had reported that start_bh_atomic()
>    and friends do no longer exist in newer 2.3 kernels. Actually I had used
>    them to prevent races between the top and bottom halves - so I've no
>    idea what will happen, if they are just skipped.

After a very short look at the current SuSE 6.4 (-> 2.2.14) sources it
appears, that ret_from_intr in entry.S does *NOT* run the bottom halfes -
except it reschedules the current process (in this case schedule() runs them).
But as long as the top half is running in the kernel, the process should not
be rescheduled. Therefore I think, that an interrupt should not be able
trigger a bottom half handler, which can interrupt the top half running in
kernel mode (-> in an UP(!!!) kernel). But I've taken only a very short look
and I could have overlooked something ...

So IMHO there is a chance, that explicit locking between the top and bottom
halfes is no longer required (for UP kernels) and is just a relict which was
required in some older kernel version (maybe 2.0???). I cannot remember ...
Probably they also have removed start_bh_atomic() and friends from recent 2.3
kernels, because it is no longer required? (in UP kernels and SMP kernels need
different locking methods anyway).

Nevertheless all the locking stuff in the drivers should be investigated very
carefully, especially SMP locking, which is currently definitely not supported
(i.e. missing) in ieee*.c.
E.g. if the start_bh_atomic() go away, then there are no locks at all, which
will prevent a top half from running on one processor while a bottom half is
running on a different processor simultaneouly. So spinlocks must be added to
protect critical regions in order to handle such situations properly.

Gerhard

Re: [hpoj-devel] kernel drivers broken with SMP

[Gerhard F. <ger...@mc...>]

David Paschal wrote:
> 
> It looks like the ieee12844 and/or ieee12844pp drivers are broken on SMP
> kernels.  Any ideas?
> 
> David

David,

IMHO there are two issues:

1. A driver, that has been compiled for an UP kernel cannot be used with
   an SMP kernel (and vice versa).
   An SMP module must be compiled using kernel header files
   which are configured for SMP (-> CONFIG_SMP) and with the
   compiler flag -D__SMP__

   Is the current Makefile prepared to compile either SMP or UP modules?
   
2. The current ieee* drivers definitely aren't fully SMP safe.
   Some time ago I had investigated this and as far as I remember there do
   *exist* a few critical regions which would require proper SMP locking.
   I think I had done these investigations with much earlier 2.2 and 2.3
   versions than the current ones and not with 2.4 (which didn't yet exist
   at this time).
   Although these SMP race conditions are probably unlikely to occur,
   they potentially do exist.

   There is one more thing, which gives me a strange feeling in my stomach,
   and that's the fact, that somebody had reported that start_bh_atomic()
   and friends do no longer exist in newer 2.3 kernels. Actually I had used
   them to prevent races between the top and bottom halves - so I've no
   idea what will happen, if they are just skipped.

I think, that the whole locking in the ieee* drivers (UP and SMP) should
definitely reinvestigated for SMP and for new kernels (2.3 and 2.4) -
probably a few (or many) things might have changed in the new kernels!

Gerhard

Re: [Hpoj-devel] color printing in OfficeJets 300/500/600/700

[Gerhard F. <ger...@mc...>]

David Paschal wrote:
> 
> Hi.  For those of you who reported problems with color printing on the
> OfficeJet 300/500/600/700 series when using the DeskJet 550C ghostscript
> driver, has anybody tried using the "DeskJet 670/680/690 series" driver
> instead?  Does it work any better?

On my OJ 500 I could successfully print with "cdj550" and "hpdj".
Hpdj uses ghostscript's ordered dithering and does not perform FS dithering in
the driver. This may be worse for pictures, but IMHO better for graphics and
text, because cdj550 uses FS dithering for everything, even for (non-black
color) text, which is IMHO not alway appropriate. It also appears, that hpdj
allows to select the print quality (draft/normal/best) and some other printer
specific features, which cannot be set with the cdj550 driver (mostly I use
hpdj with "draft" setting in the hope to save ink).
For printing pictures (i.e. photos), I think that cdj550's floyd steinberg
dithering is the better choice and results in better LPI resolution.
Also try to play with the various parameters of the drivers (see documentation
in /usr/share/ghostscript/5.50/doc/...)

Gerhard

RE: [hpoj-devel] hpoj-0.6 feedback

[dgun <dg...@ww...>]

HP-Roseville,ex1 wrote:
 > Hi, Daniel.
 > 
 > > It always happens on large scans (> about 2MB)--every time.  
 > > I haven't checked
 > > to see if it always happens at the same byte number or not, 
 > > but it always occurs
 > > on a large scan.  Scanning small images (< about 2MB) seems 
 > > to work fine.  I
 > > haven't tried enough small scans in a row to see if it's only 
 > > a problem with
 > > large scans, or if it's a problem with total data transfer 
 > > since the module was
 > > loaded.
 > In the "large scan" cases where it breaks every time, it would still be
 > helpful for me to know what scan settings you use:
 > - preview or non-preview
 > - lineart, halftone, grayscale, or color
 > - resolution
 > - geometry settings (unless scanning the whole page)
 > If I know exactly what you do I might have a better chance of reproducing
 > the problem.  In some cases different values for the above options can
 > change the timing due to changing whether the scanner or the PC is the
 > bottleneck.

I use xscanimage and have everything set to "auto".  DPI is large enough to make
scan size > 2MB (maybe anywhere from 200-600).  It's frozen when scanning
lineart, color, preview and non-preview.  Previews are full page, and scans have
crashed on both full page and partial page.

 > 
 > > If I get the right debug incantations though, I can log 
 > > everything up to the
 > > point the module hangs and try to backtrack from there.  What 
 > > do you think would
 > > be the appropriate debug parameters so that I don't get too 
 > > much info, but still
 > > get enough?
 > When I turn on debug output for the kernel drivers I generally use
 > "debug=15" for ieee12844.o and/or "debug=1" for ieee12844pp.o".  I would say
 > start with only logging ieee12844.o, and then try logging both.  If you want
 > you could also try only logging ieee12844pp.o.  Note that the output will
 > appear on the console (which can't be redirected to a file), and it should
 > also show up in syslog (possibly /var/log/messages) if syslog is configured
 > correctly.

The log looks the same whether I do ieee12844.o debug=15 or ieee12844pp.o
debug=1.  Anyway, turning on debug causes it to crash repeatably every time! 
The output is very long, but here are the last lines before it freezes:

Sep 15 23:54:54 localhost kernel:
PAR_WAIT_SET_CLEAR(l=c6159160,set=0x0000,clear=0x0040): timed out waiting for
event=9! 
Sep 15 23:54:54 localhost kernel: mlcpp0: mlcpp_intr ERROR -110 
Sep 15 23:54:54 localhost kernel:   state=5 event=9 reset=7 recv=1 rcv=0 send=2 
Sep 15 23:54:54 localhost kernel: mlc: mlcpp0: link error -110 

Then when I kill the xscanimage process, I get a bunch more output with this at
the end:

Sep 15 22:39:16 localhost kernel:
PAR_WAIT_SET_CLEAR(l=c6045160,set=0x0098,clear=0x0040): timed out waiting for
event=23! 
Sep 15 22:39:16 localhost kernel: +mlcpp0: mlcpp_intr ERROR -110 
Sep 15 22:39:16 localhost kernel:   state=7 event=23 reset=7 recv=1 rcv=0 send=2 
Sep 15 22:39:16 localhost kernel: mlc: mlcpp0: link error -110 

Similar, but different.  At this point, the module is unloadable and if I start
another process that tries to access the PSC 500, the process immediately goes
into hardware blocking (D status).

I can send you the entire file (edited for clarity) if it will help you.  Time
permitting, I'll also see if I can figure anything out.

--
Daniel
dg...@xo...

______________________________________________________
Get your free web-based email at http://www.xoom.com
Birthday? Anniversary? Send FREE animated greeting
cards for any occasion at http://greetings.xoom.com

Re: [Hpoj-devel] Problem at compile time

[Burkhard K. <bu...@bu...>]

PASCHAL,DAVID (HP-Roseville,ex1)
> > You're right David, I've hacked for a few hours since my last 
> > messages, 
> > and I've found that (apparently) the function start_bh_atomic and 
> > end_bh_atomic don't exist any more since 2.3.43.
> > So I just commented out these functions, and it compiled.
> > I can insmod the modules, and run hpo devid without errors.
> 
> Hi, Damcha.  I'm glad you got it working, but I would be a little concerned
> about just removing these calls altogether as opposed to trying to find out
> if there's a proper replacement in the newer kernels.

From looking at newer 2.4.0-test kernels I noticed that all references
to start_bh_atomic and end_bh_atomic have been removed. 
Both functions where inlines with start_bh_atomic calling 
synchronize_irq() which is a #define to barrier() in <asm/softirq.h> which 
in turn is a #define barrier() __asm__ __volatile__("": : :"memory")
in <linux/kernel.h>. 

It seems that bottom halves synchronisation in 2.4.0 now is resolved
in some automatted way.

Maybe both functions should be renamed and defined in "ieee12844.h" 
somehow like:

static void inline x_start_bh_atomic() {
#if LINUX_VERSION_CODE > KERNEL_VERSION(2,3,xxx)
#define x_start_bh_atomic()	
else
#define x_start_bh_atomic()	start_bh_atomic()
#endif
}

Inclusion of start_bh_atomic and end_bh_atomic headers in ieee12844.c
and ieee12844pp.c is not done directly from <asm/softirq.h> thus 
no particular treatment should be necessary.

BTW: I am not familiar with socket programming, why is/was
it necessary to explicitly synchronize bottom_halves? I would have
expected (maybe naively) that this issue gets handled by lower
layers. The parport driver does not use bh handlers.


Burkhard
-- 
Burkhard Kohl			buk at/auf buks.ipn.de

RE: [hpoj-devel] Re: SMP Problems with hpoj-0.6

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

> Add append="nosmp" to your lilo.conf and reboot.
You'll also need to run "lilo" after updating lilo.conf and before
rebooting.

> I have not been able to run my dual 550 PIII Xeon system in SMP mode
> since setting up hpoj.
Does using the "nosmp" parameter on an SMP-enabled kernel and SMP system, or
using an SMP-enabled kernel on a non-SMP system make the problem go away?
If so, then I won't be able to work on this, since I don't have any SMP
systems.

David

Re: [hpoj-devel] Re: SMP Problems with hpoj-0.6

[<cc...@va...>]

> > Is there any way you can run an SMP kernel but somehow force your computer
> > to only activate one CPU, either by a BIOS setup option, dip switch/jumper,
> > or physically removing one CPU (but be careful!)?  If you can duplicate
> > this problem with an SMP kernel on a uniprocessor system then I might be
> > able to scrounge up an extra PC and set it up to work on this problem if
> > nobody else can.
> There is no way to deactivate the CPU without unscrewing the machine.
> I'll try that as soon as it is possible.

Add append="nosmp" to your lilo.conf and reboot.

I have not been able to run my dual 550 PIII Xeon system in SMP mode
since setting up hpoj.

ccb


--
Charles C. Bennett, Jr.			VA Linux Systems
Systems Engineer,			25 Burlington Mall Rd., Suite 300
US Northeast Region			Burlington, MA 01803-4145
+1 617 543-6513				+1 888-LINUX-4U
cc...@va...				www.valinux.com
 vi/(emacs)  NT/(Linux)  qmail/(sendmail)  (perl)/python  (pepsi)/coke

Re: [hpoj-devel] hpoj-0.6 kernel module problem

[Burkhard K. <bu...@bu...>]

John L. Chmielewski:
> Tried the hpoj-0.6 package, and it is a great improvement over
> the earlier ones.  However, I have detected a problem with the
> kernel modules using modprobe.
> 
> The problem is that modprobe does not know to load paraport_probe.  If
> I change the modules.dep file, by hand, to make ieee12844pp depend on
> paraport_probe instead of paraport, it works as expected.  Depmod -a
> does not detect that ieee12844pp requires paraport_probe.
> 

IIRC, I have seen this prob in 0.5 already. So I configured a little
workaround into my modules.conf:
	alias parport_lowlevel    parport_pc
	add above parport lp parport_pc parport_probe ieee12844
	post-install ieee12844 modprobe "-k" ieee12844pp
	pre-remove ieee12844 rmmod ieee12844pp

This way everything gets loaded (and removed) using the right
sequence.

Burkhard 
-- 
Burkhard Kohl			bu...@bu...

Re: [hpoj-devel] Re: SMP Problems with hpoj-0.6

[Burkhard K. <bu...@bu...>]

David Paschal wrote:
> > First of all it's not a problem of version 0.6, it's more general, since
> > 0.5 make the same problems. It's really a problem of the SMP kernel:
> > (Seems I've never tested 0.5 with a SMP kernel.)
> > 
> > If I boot a non-SMP kernel and load the modules I build on this kernel,
> > it works (I've at least printed one page with ptal-connect).
> > If I boot the SMP kernel and load the SMP kernel modules it crashes at
> > "hpo devid".
> Hi, Alexander.  I feel a little better knowing that I didn't break it in
> my changes for 0.6.  :-)

Keep in mind that there is a chance that SMP related problems might
be compiler problems. From /usr/src/linux/Documentation/Changes
I know that gcc 2.7.2.3 works fine, egcs 2.91.66 now is 
considered to be o.k (although I have one testcase where a kernel
module compiled with this version does not work properly, whereas
it works with 2.7.2.3 and 2.95.2) and gcc 2.95.x versions might have 
problems.

I know this is nasty, but the compiler can make a difference.

> 
> > If I try to load the modules build with the non-SMP kernel into the
> > running SMP kernel it gives unresolved kernel symbols (and also
> > vice-versa), although the module and kernel source where the same!
> Switching between SMP and non-SMP kernels may change version information
> attached to kernel symbols.  This would cause unresolved kernel symbol
> errors as if you had switched kernel versions.
You can't mix non-SMP modules with a SMP kernel and vice versa.

Burkhard

-- 
Burkhard Kohl			bu...@bu...	

[hpoj-devel] hpoj-0.6 and R45: success

[Burkhard K. <bu...@bu...>]

Hi everyone,

I just want to report that now scanning works fine with the R45.

Burkhard
-- 
Burkhard Kohl			Tel/FAX: +49 30 698 15 905
Melchiorstr. 8			bu...@bu...
10179 Berlin			

RE: [hpoj-devel] hpoj-0.6 feedback

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

Hi, Daniel.

> It always happens on large scans (> about 2MB)--every time.  
> I haven't checked
> to see if it always happens at the same byte number or not, 
> but it always occurs
> on a large scan.  Scanning small images (< about 2MB) seems 
> to work fine.  I
> haven't tried enough small scans in a row to see if it's only 
> a problem with
> large scans, or if it's a problem with total data transfer 
> since the module was
> loaded.
In the "large scan" cases where it breaks every time, it would still be
helpful for me to know what scan settings you use:
- preview or non-preview
- lineart, halftone, grayscale, or color
- resolution
- geometry settings (unless scanning the whole page)
If I know exactly what you do I might have a better chance of reproducing
the problem.  In some cases different values for the above options can
change the timing due to changing whether the scanner or the PC is the
bottleneck.

> If I get the right debug incantations though, I can log 
> everything up to the
> point the module hangs and try to backtrack from there.  What 
> do you think would
> be the appropriate debug parameters so that I don't get too 
> much info, but still
> get enough?
When I turn on debug output for the kernel drivers I generally use
"debug=15" for ieee12844.o and/or "debug=1" for ieee12844pp.o".  I would say
start with only logging ieee12844.o, and then try logging both.  If you want
you could also try only logging ieee12844pp.o.  Note that the output will
appear on the console (which can't be redirected to a file), and it should
also show up in syslog (possibly /var/log/messages) if syslog is configured
correctly.

> OK.  I thought HP might have provided a list somewhere.
HP did provide some documentation before I joined the project, but it mainly
addressed the OfficeJet 300/500/600/700 series.  The list of OIDs recognized
by "hpo" came directly from that information, so there isn't really more to
add.

> Is it possible to just
> run through a list of numbers, or do the OID values get sent as strings?
An OID is actually a list of numbers (for example, 1.1.2.20.2.1.1 is
OID_STATUS_MSG_LINE1_PART1).  Ultimately it is transferred as a string of
bytes (binary, not ASCII, and of course no periods).  In a given device the
set of all supported OIDs (the MIB) is actually more of a tree structure, so
it's not easy to just try all possible values.  PML (and SNMP) also have a
"get next" operation, where you give it an OID and it replies with the next
supported OID and its value.  I haven't played around with this feature
much, though.

David