#1 ppbus findings

CVS_head
open
5
2005-02-06
2005-01-28
No

Hi,

I've had a look at building ppbus, taken from SF CVS today, on a NetBSD 2.0 machine (No -current at hand).

There were some problems with taking out stuff from the files that isn't in 2.0. But this was just misc stuff, unreleated to ppbus.

Another problem was that the code didn't seem to be very clean. Did you hack the kernel build framework to remove the -Werror from CFLAGS? After sprinkling some =0 to initialize variables I was fed up and didn't want to handle the rest of the problems, including some not-so-trivial ones, so I put a -Wno-error in there. I hope that the thing still built correctly, couldn't look at the remaining warnings because they scrolled out and I forgot to redirect them before.

About the operation of the driver:
It seems that only the standard mode with ieee=off works. The other modes didn't produce output. There was one exception: Once, I think with fast mode, I got two partial lines of output. They looked like the ink has finally run out, so I replaced it. Later I got some more garbage printed and noticed that only the color ink was empty and the black tank was still half full. This is great... I've sealed it and put it in the cabinet to see if it can be used later (much later, given my current print volume).

On a closer look it turned out that there were a few lines missing between the two partial lines printed before changing the ink. Seems some data was lost. With the other modes the LED at the printer usually blinked as it does normally, but nothing else happened. This is usually a sign that the printer can't understand the data it receives.

I have to admit that bidirectional communication isn't possible with my setup, because I use a simple unidirectional autoswitchbox. However, when I boot Windows it prints fine. It claims to use ECP, but I don't know if it automatically falls back to standard mode when "bidirectional support" is disabled. This was necessary to get it print over the box.

I've also tried to connect the printer directly, without the box. However I think that the cable could now be the limiting factor. It's really old and I'm not sure if it has all the necessary wires for bidirectional modes. I'm going to try again with a newer one which should be correct.

Does the ECP mode always need a bidirectional connection, even for simple jobs such as printing?

I'm happy to try further patches (if they compile in a reasonable amount of time).

Bye, Chris

Discussion

  • Gary Thorpe

    Gary Thorpe - 2005-02-02
    • assigned_to: nobody --> gathorpe
    • labels: --> miscellaneous
    • milestone: --> CVS_head
    • status: open --> pending
     
  • Gary Thorpe

    Gary Thorpe - 2005-02-02

    Logged In: YES
    user_id=779081

    Please wait a few days for a response. If you do not get a response after a few days, please email the person assigned to the request or the administrator.

     
  • Gary Thorpe

    Gary Thorpe - 2005-02-02

    Logged In: YES
    user_id=779081

    Hi,

    Thanks for your feedback. To fix any warnings generated by
    building the code, I will need the output form the compiler.
    Please post in here as a follow up. I am not sure -Werror is a
    normal CFLAG as some warnings can be safely ignored and
    should be treated as errors (to determine this, I need the
    compiler output). It may be that a release has -Werror
    (CURRENT does not). If you made changes to get it worked, I
    would appreciate a patch so I can back port this to 2.0 if
    possible.

    On printing: not all modes support output. Nibble and ps2
    modes are for reads only, and ecp and epp can only be used
    if the printer supports it. Fast mode should work though for a
    standard printer. The ieee flag indicates whether to negotiate
    mode changes or just change the mode (without negotiation,
    it is unlikely the device will respond and it won't if it complies
    with IEEE 1248). You can scan the device at run time using
    lptctl (I think the -s flag?) to see what is supported and
    whether the device understands IEEE 1248.

    Bidirectional support basically indicates that the device can
    return data to the host (i.e. reads are possible). If it is
    unidirectional only, then i think only standard and fast should
    work and maybe only nibble mode.

     
  • Christian Hattemer

    Logged In: YES
    user_id=143517

    Hi,

    first I'd like to add some things I forgot last time. Here's a dmesg snip:

    atppc0 at isa0 port 0x378-0x37f irq 7 drq 3
    atppc0: FIFO <depth,wthr,rthr>=<16,1,9>
    atppc0: capabilities=3f<INTR,DMA,FIFO,PS2,ECP,EPP>
    ppbus0 at atppc0 n2Tppbus0<1284>: error=3 status=0x87 event=24
    ppbus0<1284>: error=2 status=0x87 event=2
    Tppbus0<1284>: error=3 status=0x87 event=24
    : No IEEE1284 device found.
    lpt0 at ppbus0: mode = 1<COMPATIBLE>
    plip0 at ppbus0
    pps0 at ppbus0
    lpbb0 at ppbus0
    iic0 at lpbb0: I2C bus
    ppui0 at ppbus0
    n2Tppbus0<1284>: error=3 status=0x87 event=24
    ppbus0<1284>: error=2 status=0x87 event=2
    Tppbus0<1284>: error=3 status=0x87 event=24
    vpo_probe(ppbus0): cannot set mode to NIBBLE.

    The printer was turned off during the boot. It's a Canon S750.

    I have now replaced the cable with a newer one, which seems to work better.

    I can now set modes with ieee on and lptctl -s will now detect a device. The result of the scan appears on all consoles with a beep, like the shutdown message. This is quite annoying and should be changed to quiet logging, like the other ppbus messages.

    lptctl -r didn't work, "Operation not supported by device".
    Dunno if the printer should be able to respond to this or if it's a driver problem.

    When trying to print in ecp mode it still says:
    "ppbus_write(ppbus0): bus not in forward idle mode." with some byte count. There are messages with zero, some positive numbers and even negative numbers. The printer does nothing. Same for fast mode.

    About the source:
    I didn't know -current has no -Werror, but a release certainly has.

    I have attached a diff of the unmodified 2.0 release source and my version with ppbus hacked in. It looks like a complete mess. Dunno if it could be useful to you.

    I have only made the plain ISA part and the ppbus core compile. Other stuff, as the ISA-PNP and ACPI attachments probably don't compile because I didn't bother to remove the new stuff from -current there. Also in the parts that do compile should still be some stuff that has nothing to do with ppbus, but it didn't hurt at the moment.

    As for the compiler warnings here's a log of the warnings.

    ../../../../dev/ppbus/ppbus_msq.c: In function `ppbus_MS_microseq':
    ../../../../dev/ppbus/ppbus_msq.c:313: warning: deprecated use of label at end of compound statement
    ../../../../dev/ppbus/lpt.c: In function `lpt_request_ppbus':
    ../../../../dev/ppbus/lpt.c:270: warning: too many arguments for format
    ../../../../dev/ppbus/if_plip.c: In function `lpstart':
    ../../../../dev/ppbus/if_plip.c:890: warning: deprecated use of label at end of compound statement

    This is minus some warnings I fixed. I found one of these and attached the diff as ppbus-fixed-warnings.diff. The first two were "too many arguments for format" and the rest are uninitialized variables.

    If I forgot something again it will go in the next message.

    BTW: Did you commit changes since my first message? Seems cvs export wasn't a that good idea because I can't update now and see if/what has changed.

    Bye, Chris

     
  • Christian Hattemer

    • status: pending --> open
     
  • Christian Hattemer

    Diffs between plain 2.0 release and with ppbus hacked in

     
  • Christian Hattemer

    • status: open --> pending
     
  • Christian Hattemer

    Logged In: YES
    user_id=143517

    Hi,

    first I'd like to add some things I forgot last time. Here's a dmesg snip:

    atppc0 at isa0 port 0x378-0x37f irq 7 drq 3
    atppc0: FIFO <depth,wthr,rthr>=<16,1,9>
    atppc0: capabilities=3f<INTR,DMA,FIFO,PS2,ECP,EPP>
    ppbus0 at atppc0 n2Tppbus0<1284>: error=3 status=0x87 event=24
    ppbus0<1284>: error=2 status=0x87 event=2
    Tppbus0<1284>: error=3 status=0x87 event=24
    : No IEEE1284 device found.
    lpt0 at ppbus0: mode = 1<COMPATIBLE>
    plip0 at ppbus0
    pps0 at ppbus0
    lpbb0 at ppbus0
    iic0 at lpbb0: I2C bus
    ppui0 at ppbus0
    n2Tppbus0<1284>: error=3 status=0x87 event=24
    ppbus0<1284>: error=2 status=0x87 event=2
    Tppbus0<1284>: error=3 status=0x87 event=24
    vpo_probe(ppbus0): cannot set mode to NIBBLE.

    The printer was turned off during the boot. It's a Canon S750.

    I have now replaced the cable with a newer one, which seems to work better.

    I can now set modes with ieee on and lptctl -s will now detect a device. The result of the scan appears on all consoles with a beep, like the shutdown message. This is quite annoying and should be changed to quiet logging, like the other ppbus messages.

    lptctl -r didn't work, "Operation not supported by device".
    Dunno if the printer should be able to respond to this or if it's a driver problem.

    When trying to print in ecp mode it still says:
    "ppbus_write(ppbus0): bus not in forward idle mode." with some byte count. There are messages with zero, some positive numbers and even negative numbers. The printer does nothing. Same for fast mode.

    About the source:
    I didn't know -current has no -Werror, but a release certainly has.

    I have attached a diff of the unmodified 2.0 release source and my version with ppbus hacked in. It looks like a complete mess. Dunno if it could be useful to you.

    I have only made the plain ISA part and the ppbus core compile. Other stuff, as the ISA-PNP and ACPI attachments probably don't compile because I didn't bother to remove the new stuff from -current there. Also in the parts that do compile should still be some stuff that has nothing to do with ppbus, but it didn't hurt at the moment.

    As for the compiler warnings here's a log of the warnings.

    ../../../../dev/ppbus/ppbus_msq.c: In function `ppbus_MS_microseq':
    ../../../../dev/ppbus/ppbus_msq.c:313: warning: deprecated use of label at end of compound statement
    ../../../../dev/ppbus/lpt.c: In function `lpt_request_ppbus':
    ../../../../dev/ppbus/lpt.c:270: warning: too many arguments for format
    ../../../../dev/ppbus/if_plip.c: In function `lpstart':
    ../../../../dev/ppbus/if_plip.c:890: warning: deprecated use of label at end of compound statement

    This is minus some warnings I fixed. I found one of these and attached the diff as ppbus-fixed-warnings.diff. The first two were "too many arguments for format" and the rest are uninitialized variables.

    If I forgot something again it will go in the next message.

    BTW: Did you commit changes since my first message? Seems cvs export wasn't a that good idea because I can't update now and see if/what has changed.

    Bye, Chris

     
  • Christian Hattemer

    • status: pending --> open
     
  • Christian Hattemer

    Logged In: YES
    user_id=143517

    Turns out that dmesg looks different when the printer is on during boot. It does read the ID. However lptctl -r still does not. Everything else is unchanged.

    atppc0 at isa0 port 0x378-0x37f irq 7 drq 3
    atppc0: FIFO <depth,wthr,rthr>=<16,1,9>
    atppc0: capabilities=3f<INTR,DMA,FIFO,PS2,ECP,EPP>
    ppbus0 at atppc0 n2Tppbus0<1284>: error=3 status=0xdf event=24
    /NIBBLETn4Tppbus0<1284>: error=3 status=0xdf event=24
    ppbus0<1284>: error=1 status=0xef event=7
    TTppbus0<1284>: error=3 status=0xdf event=24
    n16Tppbus0<1284>: error=3 status=0xdf event=24
    /ECPTn16Tppbus0<1284>: error=3 status=0xdf event=24
    ppbus0<1284>: error=1 status=0xef event=7
    TTppbus0<1284>: error=3 status=0xdf event=24
    n8Tppbus0<1284>: error=3 status=0xdf event=24
    ppbus0<1284>: error=1 status=0xef event=7
    TTppbus0<1284>: error=3 status=0xdf event=24

    : IEEE1284 device found.
    ppbus0: Probing for PnP devices.
    n2Tppbus0<1284>: error=3 status=0xdf event=24
    Tppbus0: <PnP> 91 characters: M(0x4d) F(0x46) G(0x47) :(0x3a) C(0x43) a(0x61) n(0x6e) o(0x6f) n(0x6e) ;(0x3b) C(0x43) M(0x4d) D(0x44) :(0x3a) B(0x42) J(0x4a) L(0x4c) ,(0x2c) B(0x42) J(0x4a) R(0x52) a(0x61) s(0x73) t(0x74) e(0x65) r(0x72) 3(0x33) ,(0x2c) B(0x42) S(0x53) C(0x43) C(0x43) ,(0x2c) T(0x54) X(0x58) T(0x54) 0(0x30) 1(0x31) ;(0x3b) M(0x4d) D(0x44) L(0x4c) :(0x3a) S(0x53) 7(0x37) 5(0x35) 0(0x30) ;(0x3b) C(0x43) L(0x4c) S(0x53) :(0x3a) P(0x50) R(0x52) I(0x49) N(0x4e) T(0x54) E(0x45) R(0x52) ;(0x3b) D(0x44) E(0x45) S(0x53) :(0x3a) C(0x43) a(0x61) n(0x6e) o(0x6f) n(0x6e) (0x20) S(0x53) 7(0x37) 5(0x35) 0(0x30) ;(0x3b) V(0x56) E(0x45) R(0x52) :(0x3a) 1(0x31) .(0x2e) 0(0x30) 1(0x31) ;(0x3b) S(0x53) T(0x54) A(0x41) :(0x3a) 1(0x31) 0(0x30) ;(0x3b)
    ppbus0: <Canon S750> PRINTER BJL,BJRaster3,BSCC,TXT01
    lpt0 at ppbus0: mode = 1<COMPATIBLE>
    plip0 at ppbus0
    pps0 at ppbus0
    lpbb0 at ppbus0
    iic0 at lpbb0: I2C bus
    ppui0 at ppbus0
    n2Tppbus0<1284>: error=3 status=0xdf event=24
    Tvpo0 at ppbus0n8Tppbus0<1284>: error=3 status=0xdf event=24
    ppbus0<1284>: error=1 status=0xef event=7
    Tn4Tppbus0<1284>: error=3 status=0xdf event=24
    ppbus0<1284>: error=1 status=0xef event=7
    Tn2Tppbus0<1284>: error=3 status=0xdf event=24
    : cannot connect to the driveTcom0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo

    What really needs a fix are those missing linefeeds.

    BTW: Sorry for the duplicate below. SF didn't accept the attachment first because it was larger than 256000 bytes. But it did accept the message text without telling me.

     
  • Gary Thorpe

    Gary Thorpe - 2005-03-01

    Logged In: YES
    user_id=779081

    I am looking at the files you uploaded and I will be testing
    some changes based on them and on some other new
    information. The CVS has not been updated in a while, but I
    hope to change that.

    As for lptctl, it has some options on what mode to use to
    read the information (the value of the ieee parameter will
    also affect whether or not the mode change is negotiated
    with the device to do the read) so playing with this might help.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks