hpoj-devel — HPOJ development/support list

Re: [hpoj-devel] RPMs

[Gregory A. <ga...@ne...>]

Where will the RPM be located when available?

On Thu, 25 Jan 2001, Jarl Friis wrote:
> I prommised Tim to have a look at the RPMs. I haven't had time, but I
> have surfed the alps as snowborader for a week. I'll take the time to
> make one common RPM.
>
> Jarl
>
>
> _______________________________________________
> hpoj-devel mailing list
> hpo...@li...
> http://lists.sourceforge.net/lists/listinfo/hpoj-devel

-- 


**************************************
Gregory Allan <ga...@ne...>
Medical expenses or insurance eating you alive?
++ Affordable Healthcare Without Insurance ++
Get the book at:  http://affordhc.n3.net
**************************************

[hpoj-devel] RPMs

[Jarl F. <ja...@di...>]

I prommised Tim to have a look at the RPMs. I haven't had time, but I have
surfed the alps as snowborader for a week. I'll take the time to make one
common RPM.

Jarl

Re: [hpoj-devel] xojpanel replacement

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

On Saturday 20 January 2001 09:06, David Paschal wrote:

<..>
> One important thing to keep in mind for the "enterprise printer
> administrator" is to make sure it's easy to keep track of a possibly large
> number of different devices.  Of course, this principle would also apply
> for the sake of users who happened to have access to multiple devices,
> particularly when they are connected to a LAN with HP JetDirect print
> servers, rather than to a single PC, as would be typical for most "home"
> users.  (I can certainly appreciate the concerns of the multi-device user,
> since I've managed to gather up quite a collection of HP all-in-ones over
> the last year or so that I've been working on this project.:-)

The qt listview widget may still be useful in some fashon for this. In the 
'new design' that I put on my page, the listview showed several nested layers 
in the printer column, but the 'tree' was there only for illustrative 
purposes. If the listview is used, and the user is responsible for adding 
devices to the list, he/she can create either a totally flat list or a nested 
one if desired. Another property of the listview is its built-in ability to 
sort by column, which could be useful for sorting the printer list by 
ink/toner level, for example.

The listview could also be informational only, with no ability for the user 
to change entries directly.

> > The Qt designer can be used to create/modify windows very quickly, but
> > since it's designed to work with qt-2.xx , we will have to work around
> > that if we want to continue supporting qt-1.xx . 
<...>
> Sounds good to me.  I would agree that it's a good idea to avoid hand
> modifications.  Although it would be nice to support as wide a range of QT
> versions as possible, I think it will be acceptable to discontinue support
> for 1.x as long as all 2.x versions work.

I was in error regarding the designer's compatibilty with earlier versions. 
There probably would be few if any compatibility problems with ver. 2.1.x+, 
but 2.0.x versions will cause a problem. Possibly, it may not be a big one. 
When I compiled the big, complex version of the interface under qt-2.0.1, gcc 
complained about several lines, but simply commenting them out allowed it to 
build and execute without trouble. 

It seems that if the designer is to be used, a lot of time would be saved in 
creating the interfaces, but some would be lost later trying to maintain 
compatibility with earlier qt versions. If it remains easy to do, It would be 
worth the trouble, I think.

The directory structure I'm using prevents the generated files from 
overwriting hand-modified versions. The generated files are in a separate 
directory of their own. 'make' will look for them in a different directory, 
where it will find either symlinks to the generated files, or local 
hand-modified versions.

My prediction (which could be way off) is with the major improvements in kde2 
and qt, in a few months kde '1' will have nearly disappeared. The older Qt 
versions will probably disappear with it. Redhat already has  qt-2.2.3 RPMS 
available for newer systems. 

Several different Qt versions can happily coexist on the same system, making 
an upgrade easy. I have three versions installed on my box.

 
> > What would you like the binary to be called? It looks like you may be
> > considering 'xhpcontrol'.
>
> I think I came up with that name on-the-fly while I was writing that
> message. It's more generic than "xojpanel", but it still conveys the notion
> that it's an X-Windows control-panel application for HP peripherals (not
> necessarily just all-in-ones).  I discarded my first idea "xhppanel", where
> I just replaced "oj" with "hp", because I didn't think it looked good to
> have the two "p"s right next to each other.  Of course, other suggestions
> would be welcome also.

I don't have a better one.

> > Class names for an entire project often have a prefix to distinguish them
> > from classes taken from another project. If one is used, would 'HPC' be
> > acceptable as a prefix for the project's classes? An example would be
> > "HPCMainWindow_Impl::"
>
> I think that would be OK.  On the other hand, all those capital letters
> together might seem a bit overwhelming and cause the first letter of the
> next word ("Main" in your example) to get lost in the noise.  "Hpc" as a
> class name prefix ("HpcMainWindow...") might be a little more readable.

Makes sense.


> > how many device names would normally be in that user's list? What might
> > the maximum number be?
>
> If possible I would prefer to avoid setting an arbitrary maximum count for
> things like this (think linked lists, not arrays), but if it absolutely has
> to be done this way, then it should be a large number (say, 100) that is
> #defined in one place so it can be changed easily if necessary.

I agree that an arbitrary limit should not be used. I was trying to get a 
better idea of how the application would be used. The more details I can get 
about that, the more confident I'll be that what I'm making will be usable.


> > What timeline do you expect for development of this app?
>
> I don't think there's any hurry.  For the time being I'm focusing on
> improving I/O support and adding PML support to PTAL, which is a necessary
> dependency for something as complicated as xhpcontrol, particularly since I
> haven't yet finalized the PTAL PML API.

I'm only going to get it started for now. I haven't been able to do very much 
on it lately anyway, due to other projects needing work.


>I
> don't think it would be appropriate to just write kcontrol >plugins instead
> of a standalone application, because that would shut out many users who
> don't use KDE.

I won't add anything kde-specific.

>
> BTW, it occurred to me recently that you don't actually have to go to the
> trouble of loading .xpm files at runtime.  They're actually in the format
> of a .h file that you can just #include into a C/C++ application.  I
> learned a long time ago that .xbm files have this property, and I didn't
> realize that ..xpm files were the same way.  I added an entry on the TODO
> list on the web to change this when I get a chance (unless you happen to
> get to it before I do, but don't worry about it if you don't want to, and
> it's not urgent in any case).

That might be a good idea, especially if there aren't many graphics in the 
application. In a small app like xojpanel, it may make more sense to compile 
them in.

When I opened an *.xpm with a text editor, I could see the format is simply 
an array declared like this:
static char * hpoj_mini_xpm[] = { ... }

If a pixmap is chosen inside the qt designer, a similar array is added to the 
generated *.cpp file, but it's declared like this:
static const char* const image0_data[] = { ... } 

Loading graphics at runtime isn't necessarily a bad idea though. 'kdevelop' 
does it. Loading at runtime lets the user substitute his/her own graphics 
without recompiling. It also decreases the size of the binary, which in some 
cases may improve performance.

-- 
Joe

Re: [hpoj-devel] xojpanel replacement

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

Hi, Joe.

Joe Piolunek wrote:
> I was trying to create a compromise between an app for the home user and one 
> for an enterprise printer administrator, but since I don't have a very good 
> understanding of what the administrator would need, I think I compromised too 
> much in the wrong direction.
One important thing to keep in mind for the "enterprise printer administrator"
is to make sure it's easy to keep track of a possibly large number of
different devices.  Of course, this principle would also apply for the sake
of users who happened to have access to multiple devices, particularly when
they are connected to a LAN with HP JetDirect print servers, rather than to
a single PC, as would be typical for most "home" users.  (I can certainly
appreciate the concerns of the multi-device user, since I've managed to
gather up quite a collection of HP all-in-ones over the last year or so
that I've been working on this project.:-)

> The Qt designer can be used to create/modify windows very quickly, but since 
> it's designed to work with qt-2.xx , we will have to work around that if we 
> want to continue supporting qt-1.xx . What the designer does is output *.xml 
> files which have *.cpp and *.h files generated from them by the uic utility. 
> If that code contains lines that are incompatible with earlier qt versions, 
> they usually can be commented out or wrapped in '#ifdef HAVE_QT_2' or some 
> such. Hand-modifying generated code only works if you don't plan to 
> regenerate it, of course. After the generated files have been hand-modified, 
> they will always need to be hand-modified. My plan is to keep the generated 
> classes simple and add functionality by hand to an implementation class which 
> is 'cloned' from its uic-generated base class. Subclassing is the system 
> recommended by Trolltech when using the designer.
Sounds good to me.  I would agree that it's a good idea to avoid hand
modifications.  Although it would be nice to support as wide a range of QT
versions as possible, I think it will be acceptable to discontinue support
for 1.x as long as all 2.x versions work.

> To avoid unnecessary name/title changes in the code, filenames, etc., I'd 
> like to have them set as soon as they are decided upon -  
> 
> What would you like the binary to be called? It looks like you may be 
> considering 'xhpcontrol'.
I think I came up with that name on-the-fly while I was writing that message.
It's more generic than "xojpanel", but it still conveys the notion that it's
an X-Windows control-panel application for HP peripherals (not necessarily
just all-in-ones).  I discarded my first idea "xhppanel", where I just
replaced "oj" with "hp", because I didn't think it looked good to have the
two "p"s right next to each other.  Of course, other suggestions would be
welcome also.

> Class names for an entire project often have a prefix to distinguish them 
> from classes taken from another project. If one is used, would 'HPC' be 
> acceptable as a prefix for the project's classes? An example would be 
> "HPCMainWindow_Impl::"
I think that would be OK.  On the other hand, all those capital letters
together might seem a bit overwhelming and cause the first letter of the
next word ("Main" in your example) to get lost in the noise.  "Hpc" as a
class name prefix ("HpcMainWindow...") might be a little more readable.

> What would you like for the main window's title?
Either "xhpcontrol" or "HP Control Panel" would be fine for now.  It shouldn't
be too hard to change a window title later, should it?

> What user are you primarily aiming at (developer, printer admin, etc.),
(D) All of the above.  :-)

But seriously, the idea is to give the user access to all of the
PML-accessible device status and control features that are provided by the
bundled Windows software, which is especially important for the OfficeJet
500/600 series, which don't have device-based menus that let you change the
settings without PC assistance.  Even for models that do work standalone, it
would be nice to have this ability, if for no other reason than because we
can.

So to answer your question, I think it would best be targeted to both a user
as well as an administrator.  I suppose there wouldn't actually be much in it
for developers such as ourselves, other than possibly a tab or whatever at
the end to play around with raw PML, but that could just as easily be done
in a separate command-line utility.

> and 
> how many device names would normally be in that user's list? What might the 
> maximum number be?
If possible I would prefer to avoid setting an arbitrary maximum count for
things like this (think linked lists, not arrays), but if it absolutely has
to be done this way, then it should be a large number (say, 100) that is
#defined in one place so it can be changed easily if necessary.

> What would the device names look like?
Currently the PTAL device names are in the form "mlc:mlcpp0", "mlc:mlcpp1",
etc. for devices connected to a PC's parallel port, and they're in the form
"hpjd:my-jdex.my-domain.com", "hpjd:my-500x.my-domain.com:3",
"hpjd:192.54.79.33", etc. for devices connected to a JetDirect.  For the
future user-space I/O driver I'm currently working on, I'm leaning towards
names in the form "mlc:par:whatever" or "mlc:usb:whatever", where "whatever"
would be a string set by the user when starting the daemon.  It could be as
simple as "0", "1", "2", etc., or for parallel it could be an I/O port base,
such as "378", "278", "3BC", or it could be any pet name, like "ol_betsy".

(regarding my plugin proposal)
> Unfortunately, I am missing a lot of the expertise needed for this. I'm 
> reasonably sure I can set up the windows, classes, etc. for the beginning of 
> this kind of app, but almost certainly, someone else will need to assist in 
> various areas, which would probably include the plugin system. 
> 
> What timeline do you expect for development of this app?
I don't think there's any hurry.  For the time being I'm focusing on
improving I/O support and adding PML support to PTAL, which is a necessary
dependency for something as complicated as xhpcontrol, particularly since I
haven't yet finalized the PTAL PML API.

Initially I am thinking about writing some quick-and-dirty commmand-line
utilities that would provide similar functionality to xhpcontrol.  (I might
also do something similar for PML scanning and faxing before I embark on
the task of writing a proper SANE backend or whatever for this.)  Besides
helping me test PTAL, this would give me a chance to experiment and figure
out the "content" that should go into xhpcontrol.  That's one reason I
suggested the plugin idea to have maximum content flexibility.

That said, it still wouldn't hurt to at least start developing the
infrastructure: overall layout, multi-device support, and one or two simple
plugins, such as the current xojpanel functionality, just to get started.
I'll certainly be glad to help wherever you need it, and I think there are
plenty of examples to draw from as well.

PTAL is an example of a static (compile-time) plugin architecture, although
I called them "providers" rather than "plugins".  ptal.c provides the general
API, and there are two providers (ptal-hpjd.c and ptal-mlc.c) which are
registered in a table in ptal-providers.c.

A dynamic plugin architecture would use shared libraries dynamically loaded
using the "dl" functions: dlopen, dlerror, dlsym, and dlclose.  See the man
page for those functions.  Since I'm not familiar with QT programming I don't
know offhand how one would go about dynamically binding modules into a QT
class hierarchy, but I know it's possible, since it turns out that this is
exactly what KDE2 (not KDE1) control center does, as I just discovered by
reading kdebase-2.0/kcontrol/HOWTO (in the source package).  It sounds pretty
interesting, and there might be an opportunity to leverage some of their
code, since it's also licensed under the GPL.  However, I don't think it
would be appropriate to just write kcontrol plugins instead of a standalone
application, because that would shut out many users who don't use KDE.

BTW, it occurred to me recently that you don't actually have to go to the
trouble of loading .xpm files at runtime.  They're actually in the format of
a .h file that you can just #include into a C/C++ application.  I learned a
long time ago that .xbm files have this property, and I didn't realize that
.xpm files were the same way.  I added an entry on the TODO list on the web
to change this when I get a chance (unless you happen to get to it before I
do, but don't worry about it if you don't want to, and it's not urgent in
any case).

David

RE: [hpoj-devel] Connecting to Office Jet G85 on network

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

Erich K. Oliphant wrote:
> I've been poking around your site and I had a quick question.  You driver 
> supports direct parallel and network JetDirect connections.  I have a G85
(USB) 
> connected to a Win98 machine.  I'm currently connected to it via SMB and
using 
> the DeskJet 550 driver for now.  Can I connect with the stuff you guys
have?

Hi, Erich.  At the moment, as you observed, only direct-parallel and
network-JetDirect connections are supported.  I'm working on USB support,
but it's nowhere near ready to release.  In any case, there's no way to
access any of the non-printing (i.e. scanning) functionality over the
network when the G85 is connected to a Windows machine, which I think is
what you were asking about.

The best way to be able to access your G85 from both the Windows and the
Linux machine(s) would be to get a JetDirect (70X, 170X, 300X, or 500X with
firmware x.08.xx or later).  Alternatively, if you only cared about printing
from Windows, then you could just move the connection over to the Linux box
(parallel only for now), and configure Samba to share the printer over the
network for the sake of the Windows box.

Note that even though the G85 has both parallel and USB connections, it
doesn't support hot-swapping between them, so you have to power cycle the
device whenever you change which I/O port it's connected to.

David

[hpoj-devel] Connecting to Office Jet G85 on network

[Erich K. O. <er...@va...>]

Hi,
I've been poking around your site and I had a quick question.  You =
driver supports direct parallel and network JetDirect connections.  I =
have a G85 (USB) connected to a Win98 machine.  I'm currently connected =
to it via SMB and using the DeskJet 550 driver for now.  Can I connect =
with the stuff you guys have?

Thanks

Re: [hpoj-devel] hpoj on HP PSC500 Scanner/Copier/Printer

[John S. <xf...@di...>]

David

This is quite a service!

I'm away from the office at the moment and I haven't managed to get the
remote access bits of the new SuSE installation to accept IP addresses,
so I can't dial back in yet.

To much irrelevant information? Probably.

I'll report back as soon as I get a chance to try it.

Thanks

John

  

David Paschal wrote:
> 
> John Simpson wrote:
> > Only problem is, the printer has to be on when the Linux box is
> > switched on otherwise the ieee12844pp module doesn't load. This is a
> > major problem when inexperienced users have control of the system,
> > which in my case is most of the time. Have I missed something? Are
> > there some switches I can pass to the module to force it to load?
> Hi, John.  Please try the attached patch for ieee12844pp.c.  It's a quick
> and dirty hack to remove the annoying requirement that the peripheral be
> connected and powered on when the module is loaded.  I only made sure it
> compiled and didn't actually test it, so I don't know if there will be any
> problems.  It should work, however, and I think the only problem would
> arise if you happened to have multiple parallel ports, in which case
> mlc:mlcpp0 might turn into mlc:mlcpp1.  Let me know how it works out for
> you.
> 
> David
be

Re: [hpoj-devel] hpoj on HP PSC500 Scanner/Copier/Printer

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

John Simpson wrote:
> Only problem is, the printer has to be on when the Linux box is
> switched on otherwise the ieee12844pp module doesn't load. This is a
> major problem when inexperienced users have control of the system,
> which in my case is most of the time. Have I missed something? Are
> there some switches I can pass to the module to force it to load? 
Hi, John.  Please try the attached patch for ieee12844pp.c.  It's a quick
and dirty hack to remove the annoying requirement that the peripheral be
connected and powered on when the module is loaded.  I only made sure it
compiled and didn't actually test it, so I don't know if there will be any
problems.  It should work, however, and I think the only problem would
arise if you happened to have multiple parallel ports, in which case
mlc:mlcpp0 might turn into mlc:mlcpp1.  Let me know how it works out for
you.

David

[hpoj-devel] hpoj on HP PSC500 Scanner/Copier/Printer

[John S. <xf...@di...>]

Hi

Everything works fine after a few hiccups.

Only problem is, the printer has to be on when the Linux box is switched
on otherwise the ieee12844pp module doesn't load. This is a major
problem when inexperienced users have control of the system, which in my
case is most of the time. Have I missed something? Are there some
switches I can pass to the module to force it to load?

Thanks

John Simpson
http://dialspace.dial.pipex.com/john_simpson/

Re: [hpoj-devel] hpo fails on HP PSC500

[John S. <xf...@di...>]

All ok. now. 

Problem was the parallel port set to SPP. 

Both scanning and printing working.

Thanks

John Simpson wrote:
> 
> Hi
> 
> Modules installed correctly but hpo gives failures as follows:
> 
> hpo devid
> Error 5 (system error 110) in file mlccon.c, line 93:
> Connection to peripheral lost
> 
> hpo get OID_STATUS_MSG_LINE1_PART1
> Error 0 (system error 110) in file mlccon.c, line 263:
> Unexpected Error, please post a bug report.....
> 
> This is the bug report
> 
> I'm using an HP PSC 500
> 
> Autoprobe produces the following
> 
> CLASS:PRINTER;
> MODEL:PSC 500;
> MANUFACTURER:HEWLETT-PACKARD;
> DESCRIPTION:Hewlett-Packard PSC 500;
> COMMAND SET:MLC,PCL,PML,SCL;
> 
> I'm using SuSE 7.0 2.2.16
> 
> I'm hoping to get the scanner part of the PSC500 working using Sane
> 
> John Simpson
> 
> _______________________________________________
> hpoj-devel mailing list
> hpo...@li...
> http://lists.sourceforge.net/lists/listinfo/hpoj-devel

Re: [hpoj-devel] xojpanel replacement

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

On Wednesday 10 January 2001 08:55, David Paschal wrote:

> Joe Piolunek wrote:
> > I've started working again on an 'xojpanel replacement' that should be
> > much more functional.

<...>
> I'm not sure that the new version will totally accomplish
> that.  It appears that the user would have to do too much clicking to go
> through the list of devices and check the status on each one, if there
> happened to be multiple devices available.  Even if you put the LCD panel
> on the printer selection dialog box, that wouldn't help me if I wanted to
> check the ink/toner levels on each device, for example, and if you kept
> adding more "shortcuts" like this to the printer selection dialog box,
> then it would end up getting quite cluttered as well.

I went back to the old design and have it building under hpoj-0.7/apps/. It 
will be easy to modify the windows' appearance to fit whatever you want it to 
look like, especially if done early in the process.

When I have the window looking more acceptable, I'll update my web page, 
adding current screenshots.

I was trying to create a compromise between an app for the home user and one 
for an enterprise printer administrator, but since I don't have a very good 
understanding of what the administrator would need, I think I compromised too 
much in the wrong direction.

About modifying the appearance of the windows -

The Qt designer can be used to create/modify windows very quickly, but since 
it's designed to work with qt-2.xx , we will have to work around that if we 
want to continue supporting qt-1.xx . What the designer does is output *.xml 
files which have *.cpp and *.h files generated from them by the uic utility. 
If that code contains lines that are incompatible with earlier qt versions, 
they usually can be commented out or wrapped in '#ifdef HAVE_QT_2' or some 
such. Hand-modifying generated code only works if you don't plan to 
regenerate it, of course. After the generated files have been hand-modified, 
they will always need to be hand-modified. My plan is to keep the generated 
classes simple and add functionality by hand to an implementation class which 
is 'cloned' from its uic-generated base class. Subclassing is the system 
recommended by Trolltech when using the designer.

Qt-2.2.3 works extremely well. It's worth installing, but it needs a lot of 
disk space if building from source. You can now get Qt under the GPL if you 
are developing free software or simply using qt applications.


> Looking back at your earlier screenshots based on my original idea, I'll
> admit they do seem a bit cluttered and overwhelming.  I still think a
> somewhat simplified version of this idea would be quite effective,
> however:
>
> - On the left, have a flat (non-hierarchical) list of all known PTAL
> device names (perhaps from a file such as /etc/xhpcontrol.conf).  

I'll make the windows look more or less the way you want them to.
 
To avoid unnecessary name/title changes in the code, filenames, etc., I'd 
like to have them set as soon as they are decided upon -  

What would you like the binary to be called? It looks like you may be 
considering 'xhpcontrol'.

Class names for an entire project often have a prefix to distinguish them 
from classes taken from another project. If one is used, would 'HPC' be 
acceptable as a prefix for the project's classes? An example would be 
"HPCMainWindow_Impl::"

What would you like for the main window's title?

>One could argue that it's not user-friendly to let the PTAL device names all
> hang out like this, but I want to avoid falling into the trap of over-
> obfuscation that Windows-based applications tend to fall into, which
> ultimately only makes things more difficult when one really needs to know
> what's going on behind the scenes.  You could always allow a user-defined
> comment (possibly indication location or ownership of the device) to be
> displayed either in this list or in one of the tabs...

What user are you primarily aiming at (developer, printer admin, etc.), and 
how many device names would normally be in that user's list? What might the 
maximum number be? What would the device names look like?

>
> - On the right, have the (infamous?) tabs, but it might be better not to
> have nested tabs as in your earlier example.  This way, one could click
> on the first device and the desired tab (LCD or ink levels, for example),
> then click on each successive device and the same tab would stay selected
> and would update itself for each successive device.
>

More than one row of tabs is generally to be avoided. It occurred with the 
'fax' tab because there is so much information in that category. I'll remove 
the nested row soon and perhaps show it in a different 'popup' window later.

> - As an alternative to tabs, we could use the KDE control panel as an
> example, with its (possibly hierarchical) list of categories of options
> in the middle, and once a category is selected, the actual dialog box for
> it on the right.

Sounds like a good alternative.

>
> - I envision that this application could be made useful for most HP
> peripherals, not just the all-in-ones.  Therefore, I think it would be
> better to have some sort of plugin architecture, where each plugin would
> define and register one or a small number of option categories (tabs or
> whatever), and the application would handle the device list and would
> notify plugins when a different device or category was selected so the
> plugin could redraw its share of the dialog box and handle user event
> such as clicking on buttons or whatever.
>
> Besides making it easy to support a larger variety of HP peripherals,
> using plugins would allow a much cleaner and modular design for the
> application, and would give much more flexibility in defining the actual
> categories of control/status options and their contents, rather than if
> they were all hard-coded in a monolithic design.
>
> Plugins could be loaded at runtime as shared libraries, or they could be
> statically compiled into the application while still being cleanly
> separated from the main part of the application.
>

Unfortunately, I am missing a lot of the expertise needed for this. I'm 
reasonably sure I can set up the windows, classes, etc. for the beginning of 
this kind of app, but almost certainly, someone else will need to assist in 
various areas, which would probably include the plugin system. 

What timeline do you expect for development of this app?

> Of course, I'm not a user-interface expert, which explains why my job is
> firmware development, not GUI design.  :-)

Me neither.

-- 
Joe

[hpoj-devel] hpo fails on HP PSC500

[John S. <xf...@di...>]

Hi

Modules installed correctly but hpo gives failures as follows:

hpo devid
Error 5 (system error 110) in file mlccon.c, line 93:
Connection to peripheral lost

hpo get OID_STATUS_MSG_LINE1_PART1
Error 0 (system error 110) in file mlccon.c, line 263:
Unexpected Error, please post a bug report.....

This is the bug report

I'm using an HP PSC 500

Autoprobe produces the following

CLASS:PRINTER;
MODEL:PSC 500;
MANUFACTURER:HEWLETT-PACKARD;
DESCRIPTION:Hewlett-Packard PSC 500;
COMMAND SET:MLC,PCL,PML,SCL;

I'm using SuSE 7.0 2.2.16

I'm hoping to get the scanner part of the PSC500 working using Sane


John Simpson

[hpoj-devel] RE:Insmod fails

[John S. <xf...@di...>]

Burkhard

The FORCE_SMP part of the ieee12844 makefile doesn't seem to work

I undefined __SMP__ in the ieee12844*.c files, recompiled and the
modules installed ok.


John 
> Burkhard
> 
> My kernel isn't compiled with SMP support (from /proc/config.gz). I've
> tried modifying the ieee12844/Makefile.in (then make clean etc.) both
> with and without SMP support and I get the same result.
> 
> Any ideas?
> 
> John
> 
> Burkhard Kohl wrote:

> 
> John Simpson
> > Hi
> >
> > I'm having trouble installing the ieee12844 modules from hpoj-0.7
> >
> > My kernel seems to be configured correctly; the output from
> > /proc/config.gz shows the following:
> >
> > CONFIG_PARPORT=m
> > CONFIG_PARPORT_PC=m
> > CONFIG_PNP=y
> > CONFIG_PNP_PARPORT=m
> >
> > The parport modules all load ok, but the ieee12844 modules fail with
> > unresolved symbols as follows:
> >
> > ieee12844.0 - global_bh_lock, synchonize_bh
> These function calls will be undefined when you have compiled the
> ieee12844 modules with SMP support and try to load them with a
> non-SMP kernel environment.
> 
> Depending on what you really want, you have to reconfig your kernel
> or recompile it. Or you might force non-SMP support by defining
> FORCE_SMP with a value different than "SMP" in the ieee12844/Makefile.
> 
> > ieee12844pp,o - same, plus tqueue_lock, mlcp_unregister, mlcp_register
> These should all be consequences of ieee12844.o not being loaded.
> 
> Burkhard
> --
> Burkhard Kohl                   bu...@bu...
> 
> _______________________________________________
> hpoj-devel mailing list
> hpo...@li...
> http://lists.sourceforge.net/mailman/listinfo/hpoj-devel

[hpoj-devel] Red Hat vs SuSe initscript

[Maurizio S. <m.s...@is...>]

  Looking at the hpoj packages by Jarl Friis (thanks for your previous 
answer) seems to me that the main difference between RedHat and SuSe dists is 
the init.d  & rc.d directory tree (/sbin for SuSe, /etc for Red Hat).

  Another thing to look at is the correct place for ieee12844*.o modules, and 
I don't know if it is dist-dependant (I only  know Red Hat) ; the same place 
fo parport* mods could be a solution.

  Since ptal-printd creates a special file pointed by /etc/printcap, lpd 
blocks when it is re/started before ptal-printd does, so lpd initscript must 
look at ptal-printd or manage it. Another solution could be to force lpd to 
restart from a different file such /etc/printcap.hpoj by ptal-printd script.

  I am a hpoj user not a developer, so excuse me for these maybe-boring 
instances.

  Bye

[hpoj-devel] To Timothy Lee

[Jarl F. <ja...@di...>]

Hi Timothy, I have tried to send you an email, but fail with the error:
Final-Recipient: RFC822; l_t...@us...
Action: failed
Status: 5.5.0
Remote-MTA: DNS; mxpool01.netaddress.usa.net
Diagnostic-Code: SMTP; 550 Mail from 202.181.234.37 refused.  UNL.
Last-Attempt-Date: Fri, 12 Jan 2001 21:11:17 +0800                                                                         

I don't know if it's cause of my system or yours. The real problem will
eventually come if I need to attach something to you and not the whole
list.

I just wanted to tell you that I havn't looked at your SRPM yet, but I
guess I'll do it in the weekend, and send you a suggestion for a common
SRPM (for both SuSE and Redhat).

Jarl

  

Re: [hpoj-devel] insmod fails

[John S. <xf...@di...>]

Burkhard

My kernel isn't compiled with SMP support (from /proc/config.gz). I've
tried modifying the ieee12844/Makefile.in (then make clean etc.) both
with and without SMP support and I get the same result.

Any ideas?

John

Burkhard Kohl wrote:
> 
> John Simpson
> > Hi
> >
> > I'm having trouble installing the ieee12844 modules from hpoj-0.7
> >
> > My kernel seems to be configured correctly; the output from
> > /proc/config.gz shows the following:
> >
> > CONFIG_PARPORT=m
> > CONFIG_PARPORT_PC=m
> > CONFIG_PNP=y
> > CONFIG_PNP_PARPORT=m
> >
> > The parport modules all load ok, but the ieee12844 modules fail with
> > unresolved symbols as follows:
> >
> > ieee12844.0 - global_bh_lock, synchonize_bh
> These function calls will be undefined when you have compiled the
> ieee12844 modules with SMP support and try to load them with a
> non-SMP kernel environment.
> 
> Depending on what you really want, you have to reconfig your kernel
> or recompile it. Or you might force non-SMP support by defining
> FORCE_SMP with a value different than "SMP" in the ieee12844/Makefile.
> 
> > ieee12844pp,o - same, plus tqueue_lock, mlcp_unregister, mlcp_register
> These should all be consequences of ieee12844.o not being loaded.
> 
> Burkhard
> --
> Burkhard Kohl                   bu...@bu...
> 
> _______________________________________________
> hpoj-devel mailing list
> hpo...@li...
> http://lists.sourceforge.net/mailman/listinfo/hpoj-devel

Re: [hpoj-devel] SRPM for hpoj-0.7

[Jarl F. <ja...@di...>]

On Wed, 10 Jan 2001, David Paschal wrote:

> Timothy Lee wrote:
> > Now, about the SRPM for RedHat:  I've written up a readme file documenting
> > the difference between installing from RPM and tarball.  If anyone should
> > care to comment on it, I'm all ears.
> Hi, Timothy.  Your README file looks good, although I would suggest that you
> remove the hyphen from "make-install", since the command is "make install".
> 
> > The SRPM has been modified to include this readme file.  In addition,
> > /etc/rc.d/init.d/ptal-printd now finds the daemon even with relocated RPM
> > packages (prefix other than /usr).
> > 
> > David, I believe the SRPM is almost ready for release.  What are your
> > thoughts?
> Have you had a chance to check out Jarl's [S]RPM packages?  It's too bad
> that there ended up being some duplicate effort here, but I only want to
> post a single SRPM package (which can be built into a binary RPM package
> for multiple platforms).

Well, can I have a look on the SRPM intended for Redhat (a URL or
attachment for me, i.e. not list) , then I could maybe add changes to
reflect the extra SuSE stuff surrounded by if (SuSE) ... endif or however
this is done in SPEC files, but I really suggest that the SRPM reflect the
conceptually different packages that the source contain;

1) a kernel module
2) a library (ptal) (currently depending on (1) )
3) basic commandline tools for the library. (depending on (2) )
Eventually: 4) advanced tools/frontends (xojpanel, etc. ) (depending on
               (2) )

Which during build-time will result in 3/4 RPMs

Jarl

Re: [hpoj-devel] SRPM for hpoj-0.7

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

Timothy Lee wrote:
> Now, about the SRPM for RedHat:  I've written up a readme file documenting
> the difference between installing from RPM and tarball.  If anyone should
> care to comment on it, I'm all ears.
Hi, Timothy.  Your README file looks good, although I would suggest that you
remove the hyphen from "make-install", since the command is "make install".

> The SRPM has been modified to include this readme file.  In addition,
> /etc/rc.d/init.d/ptal-printd now finds the daemon even with relocated RPM
> packages (prefix other than /usr).
> 
> David, I believe the SRPM is almost ready for release.  What are your
> thoughts?
Have you had a chance to check out Jarl's [S]RPM packages?  It's too bad
that there ended up being some duplicate effort here, but I only want to
post a single SRPM package (which can be built into a binary RPM package
for multiple platforms).

David

Re: [hpoj-devel] for the IEEE1284 developers

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

Jarl Friis wrote:
> I just read a newsgroup and saw a release of a EPP utility, maybe it will
> help you the ongoing development of the IEEE1284 driver, if not please
> ignore this message.
> 
> The utility can be found at 
> http://www.scn.org/~nedu/eppio.html
Hi, Jarl.  Thanks for the pointer.  I took a look at it, but it won't
actually be useful for the hpoj project, because that driver implements
the EPP (Enhanced Parallel Port) protocol, whereas most if not all HP
peripherals use the ECP (Extended Capabilities Port) protocol, which is
what the hpoj driver implements.

David

Re: [hpoj-devel] 2.4 kernel issues

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

Burkhard Kohl wrote:
> I think the debug messages were a bit misleading. I resolved this
> to be a failure during the transmit mode negotiation phase due 
> to the parport being set to reverse mode. This can be cured by
> inserting a 
> 	parport_data_forward(l->port);
> statement just before the 
> 	parDataWrite(l, ...);
> statement of event 0. (or inside the parDataWrite() function call).
> 
> But now the driver runs into another problem - the peripheral answers
> the hosts MLCConfigSocket command for socket 1 with MLCError 7 after
> a succesful MLCInit/InitReply pair

Hi, Burkhard.  MLC Error 7 means that a packet was received for a channel
that wasn't open, meaning that one or both of the first tso bytes of the
packet (in this case, the ConfigSocket command) was incorrect.  However,
your debug output seemed correct, so perhaps there's a timing issue
associated with the change you made (see above) which causes the data
lines not to be stable (i.e. not the value you wrote to them) when the
peripheral is trying to read them.  You could try putting a short delay
after writing the data lines and before setting nStrobe to 0 when sending
the data byte.

> From the parport driver sources I see that there is no BECP support 
> for now - do you expect to have it in the near future? In ieee12844pp.c
> there is actually only one event (41) referring to becp when switching
> from ecp reverse to forward when the peripheral is idle.
Bounded ECP mode is essentially regular ECP mode with some added restrictions
placed on the host and peripheral.  It's documented in the 1284.3 spec
(which may or may not be released yet).  For our purposes, I don't think
we actually need kernel support for it, since ieee12844pp.c is handling
all of the signalling itself.

David

Re: [hpoj-devel] xojpanel replacement

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

Joe Piolunek wrote:
> I've started working again on an 'xojpanel replacement' that should be much 
> more functional. 
> 
> An earlier version that I had put together just got too big and complicated, 
> so I started over from scratch. The newer version looks a lot better, I think.
> It may still be too early to decide exactly how the application should look 
> or what it should contain, but the more thought put into it in the beginning, 
> the better, IMHO.
> 
> I have the application building into a new directory under hpoj-0.7/apps/. 
> It's a little too early to make the code available. There isn't much of it 
> yet.
> 
> On my site are screenshots of the two windows created so far. These are 
> 'previews' created by the Qt designer.
> 
> The web server has been a little messed up, so if you don't see a page with 
> OfficeJet GUI screenshots, try again later.
> 
> http://pages.cthome.net/jsp/hpoj-linux-gui/index.html
> 
> Is it worth continuing in this direction? Let me know what you think.

Hi, Joe.  Thanks for revising this.  Sorry I didn't respond until now.
I started back at work at the end of last week after being on vacation for
two weeks and have been trying to catch up a lot there.  :-)

Although I applaud your efforts to simplify the application and make it
easier to use, I'm not sure that the new version will totally accomplish
that.  It appears that the user would have to do too much clicking to go
through the list of devices and check the status on each one, if there
happened to be multiple devices available.  Even if you put the LCD panel
on the printer selection dialog box, that wouldn't help me if I wanted to
check the ink/toner levels on each device, for example, and if you kept
adding more "shortcuts" like this to the printer selection dialog box,
then it would end up getting quite cluttered as well.

Looking back at your earlier screenshots based on my original idea, I'll
admit they do seem a bit cluttered and overwhelming.  I still think a
somewhat simplified version of this idea would be quite effective,
however:

- On the left, have a flat (non-hierarchical) list of all known PTAL
device names (perhaps from a file such as /etc/xhpcontrol.conf).  One
could argue that it's not user-friendly to let the PTAL device names all
hang out like this, but I want to avoid falling into the trap of over-
obfuscation that Windows-based applications tend to fall into, which
ultimately only makes things more difficult when one really needs to know
what's going on behind the scenes.  You could always allow a user-defined
comment (possibly indication location or ownership of the device) to be
displayed either in this list or in one of the tabs...

- On the right, have the (infamous?) tabs, but it might be better not to
have nested tabs as in your earlier example.  This way, one could click
on the first device and the desired tab (LCD or ink levels, for example),
then click on each successive device and the same tab would stay selected
and would update itself for each successive device.

- As an alternative to tabs, we could use the KDE control panel as an
example, with its (possibly hierarchical) list of categories of options
in the middle, and once a category is selected, the actual dialog box for
it on the right.

- I envision that this application could be made useful for most HP
peripherals, not just the all-in-ones.  Therefore, I think it would be
better to have some sort of plugin architecture, where each plugin would
define and register one or a small number of option categories (tabs or
whatever), and the application would handle the device list and would
notify plugins when a different device or category was selected so the
plugin could redraw its share of the dialog box and handle user event
such as clicking on buttons or whatever.

Besides making it easy to support a larger variety of HP peripherals,
using plugins would allow a much cleaner and modular design for the
application, and would give much more flexibility in defining the actual
categories of control/status options and their contents, rather than if
they were all hard-coded in a monolithic design.

Plugins could be loaded at runtime as shared libraries, or they could be
statically compiled into the application while still being cleanly separated
from the main part of the application.

Of course, I'm not a user-interface expert, which explains why my job is
firmware development, not GUI design.  :-)

David

Re: [hpoj-devel] initscript

[Jarl F. <ja...@di...>]

On Tue, 9 Jan 2001, Maurizio Scaglione wrote:

>   Where could I find the SRPM version of hpoj?

On http://213.237.48.227/~jarl/hpoj/

It will be down some hours later today and tomorrow.

Jarl

[hpoj-devel] initscript

[Maurizio S. <m.s...@is...>]

  Where could I find the SRPM version of hpoj?

[hpoj-devel] SRPM for hpoj-0.7

[Timothy L. <ti...@wo...>]

Burkhard Kohl wrote:

> as long as you are using big5 charset me (and probably others)
> won't be able to read your messages.

Oops...  never noticed that....  Most of my other correspondence are in
Chinese, so big5 is my default.  Sorry.

Now, about the SRPM for RedHat:  I've written up a readme file documenting
the difference between installing from RPM and tarball.  If anyone should
care to comment on it, I'm all ears.

The SRPM has been modified to include this readme file.  In addition,
/etc/rc.d/init.d/ptal-printd now finds the daemon even with relocated RPM
packages (prefix other than /usr).

David, I believe the SRPM is almost ready for release.  What are your
thoughts?


     Timothy Lee

Re: [hpoj-devel] insmod fails

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

John Simpson
> Hi
> 
> I'm having trouble installing the ieee12844 modules from hpoj-0.7
> 
> My kernel seems to be configured correctly; the output from
> /proc/config.gz shows the following:
> 
> CONFIG_PARPORT=m
> CONFIG_PARPORT_PC=m
> CONFIG_PNP=y
> CONFIG_PNP_PARPORT=m
> 
> The parport modules all load ok, but the ieee12844 modules fail with
> unresolved symbols as follows:
> 
> ieee12844.0 - global_bh_lock, synchonize_bh
These function calls will be undefined when you have compiled the
ieee12844 modules with SMP support and try to load them with a
non-SMP kernel environment.

Depending on what you really want, you have to reconfig your kernel
or recompile it. Or you might force non-SMP support by defining 
FORCE_SMP with a value different than "SMP" in the ieee12844/Makefile.

> ieee12844pp,o - same, plus tqueue_lock, mlcp_unregister, mlcp_register
These should all be consequences of ieee12844.o not being loaded.


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