libieee1284

Logged In: NO

As the ChangeLog shows [1], Tim Waugh took the patch into CVS. Great.
Now we only need a release to get it into distributions.

[1]
http://libieee1284.cvs.sourceforge.net/libieee1284/libieee1284/ChangeLog?revision=1.155&view=markup

Logged In: NO

The mentioned patch went into Debian unstable in libieee1284 (0.2.10-8)
[1].

Best regards,

Philipp

[1]
http://packages.debian.org/changelogs/pool/main/libi/libieee1284/libieee1284_0.2.10-8/changelog#versionversion0.2.10-8

Logged In: NO

I'm unsure, but think that the change to forceing nlink to 0 on dirs and 1
on files at /proc was due to several link count problems in incorrectly
(un)registering several devices.

I'm trying to find the lkml thread discussion on it.
In the meantime, I've sent your patch and disscusion to lkml and redhat
bugzilla

Logged In: NO

difference between .18 and .22 is in number of links (column 2 .. next to
privileges and before owner). This represents number of links (for normal
directory minimum 2 links exist, one for "." second for "..", this number
must be more then 2 for parport directory if there exist "file" for
parport (or default). Library checks this value, but ?kernel? is wrong for
proc filesystem, for all files/directories zero is reported for link
count. If this is feature for new kernel proc interface, this is silly
feature.

Logged In: NO

Hi krak3n,

you made my day, thanks.
Your patch works for me, even if I don't see the difference between the
listings of /proc/sys/dev/parport on .18 and .22

Now we have to get the solution upstream or into distributions.

Best regards,

Philipp

Logged In: NO

/proc on on 2.6.22.1

# ls -la /proc/sys/dev/parport
total 0
dr-xr-xr-x 0 root root 0 2007-08-03 08:21 .
dr-xr-xr-x 0 root root 0 2007-08-03 08:19 ..
dr-xr-xr-x 0 root root 0 2007-08-03 08:25 default
dr-xr-xr-x 0 root root 0 2007-08-03 08:25 parport0

on 2.6.18
# ls -la /proc/sys/dev/parport/
total 0
dr-xr-xr-x 4 root root 0 Aug 3 08:29 .
dr-xr-xr-x 7 root root 0 Aug 3 08:29 ..
dr-xr-xr-x 2 root root 0 Aug 3 08:29 default
dr-xr-xr-x 3 root root 0 Aug 3 08:29 parport0

src/detect.c, function check_proc_type (void)

if (stat ("/proc/sys/dev/parport", &st) == 0 &&
S_ISDIR (st.st_mode) &&
st.st_nlink > 2)

This test fail on st.st_nlink > 2 for kernels with new proc interface for
parport.

patch:

% diff -u detect.c.orig detect.c
--- detect.c.orig 2007-08-03 09:27:29.000000000 +0200
+++ detect.c 2007-08-03 09:27:46.000000000 +0200
@@ -69,8 +69,7 @@
int which = 0;
struct stat st;
if (stat ("/proc/sys/dev/parport", &st) == 0 &&
- S_ISDIR (st.st_mode) &&
- st.st_nlink > 2)
+ S_ISDIR (st.st_mode))
{
which = PROC_SYS_DEV_PARPORT_CAPABLE;
debugprintf ("This system has /proc/sys/dev/parport\n");



--
krak3n

Logged In: NO

Thanks Juan Antonio for keeping the others updated.
The LKML discussion suddenly stopped, which is unfortunate.

I'd like to help in resolving that issue, but booting with the suggested
boot options to disable isapnp didn't change anything on my system.

Best regards,

Philipp

Logged In: NO

Unfortunately no news.

kernel 2.6.21 is an first attemp to change the parport layer. My feeling
is that
no real interest exists in testing until 2.6.22 is up and new parport
layer fully
implemented
( I use 2.6.21.5, no time to download and test a 2.6.22rcX version, sorry
)

The error seems to be in handling claim() ioctl at parport.c module
(called
from ppdev.c ), but is so difficult to trace... and as I saw, parport
layer in
2.6.21 seems to be unstable and in process of change ( too many changes
for
this version IMHO )

At these moment you have two "solutions"
- Remove /lib/modules/$kversion/drivers/char/ppdev.ko module
- If your app uses libieee1284, disable use of ppdev by mean of
/etc/ieee1284.conf

The (sort) lkml discusion is here:
http://marc.info/?l=linux-kernel&m=118336819012256&w=2

Juan Antonio

Logged In: NO

Are there any news on that bug?
Could someone please link to the discussion on LKML?
It would be great if we can link all information to that problem to help
resolving it as fast as possible.

Logged In: NO

Files ppdev.h and parport.h included in CVS sligthly differs from kernels
2.6.21 and up.

kernel file drivers/char/ppdev.c has been stable until 2.6.21.5 . Newer
kernel version changed their behaviour. Same applies to
include/linux/parport.h and in general to all parport layer

libieee1284 fails in claim() returning E1284_SYS (System Call Error).
Failed line is "ioctl(port->fd, PPCLAIM)" from access_ppdev.c

Studing ppdev.c seems that parport_claim_or_block() fails. Need further
study

Reported at bugzilla Fedora and Linux-kernel mailing list

Logged In: NO

yes that works but another stupid question how is it possible to use the
parport as a normal user ? (setting permissions for /dev/parport0
/dev/ports doesn't work)

Logged In: NO

If you create /etc/ieee1284 with this content:

[root@drake char]# cat /etc/ieee1284.conf
# Needed for mustek_pp and some other parallel port Sane backends
disallow method ppdev
[root@drake char]#
(That is, disable use of ppdev)

Everything works fine

I've noticed & reported same error in Fedora 7:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246406

Logged In: NO

now i can ensure that it is kernel specific (or an arch linux problem with
the kernel 2.6.21.5 configuration)

becouse i just changed the kernel on the same distro (arch linux) from
2.6.20.10 to 2.6.21.5 and with the 2.6.20.10 it worked veryl well with the
2.6.21.5 it doesn't work (the problem which is reported)

Logged In: NO

under ubuntu 7.04 final with kernel 2.6.20 it works

Logged In: NO

A duplicate bug is reported at
http://bugs.archlinux.org/task/7438?histring=parport

Logged In: NO

the same with 2.6.21.5 kernel on archlinux
[root@Johannes johannes]# LIBIEEE1284_DEBUG=123 sane-find-scanner -p

# sane-find-scanner will now attempt to detect your scanner. If the
# result is different from what you expected, first make sure your
# scanner is powered up and properly connected to your computer.

# No SCSI scanners found. If you expected something different, make sure
that
# you have loaded a kernel SCSI driver for your SCSI adapter.
# Also you need support for SCSI Generic (sg) in your operating system.
# If using Linux, try "modprobe sg".

found USB scanner (vendor=0x04fc, product=0x0561) at libusb:004:005
found USB scanner (vendor=0x067b, product=0x2303) at libusb:004:004
# Your USB scanner was (probably) detected. It may or may not be
supported by
# SANE. Try scanimage -L and read the backend's manpage.
/dev/parport0 is accessible
We can use ioperm()
/dev/port is accessible
==> ieee1284_open
==> init_port
Got 0 from ppdev init
<== 0
==> claim
<== E1284_SYS
==> ieee1284_open
==> init_port
Got 0 from ppdev init
<== 0
==> claim
<== E1284_SYS
==> ieee1284_open
==> init_port
Got 0 from ppdev init
<== 0
==> claim
<== E1284_SYS
==> ieee1284_open
==> init_port
Got 0 from ppdev init
<== 0
==> claim
<== E1284_SYS
==> ieee1284_open
==> init_port
Got 0 from ppdev init
<== 0
==> claim
<== E1284_SYS
==> ieee1284_open
==> init_port
Got 0 from ppdev init
<== 0
==> claim
<== E1284_SYS

# No Mustek parallel port scanners found. If you expected something
# different, make sure the scanner is correctly connected to your
computer
# and you have apropriate access rights.

# Most Scanners connected to the parallel port or other proprietary
ports
# can't be detected by this program.

Logged In: NO

A bit more debug output:

(this is on linux 2.6.22-rc6

LIBIEEE1284_DEBUG=123 sane-find-scanner -p

# sane-find-scanner will now attempt to detect your scanner. If the
# result is different from what you expected, first make sure your
# scanner is powered up and properly connected to your computer.

# No SCSI scanners found. If you expected something different, make sure
that
# you have loaded a kernel SCSI driver for your SCSI adapter.
# Also you need support for SCSI Generic (sg) in your operating system.
# If using Linux, try "modprobe sg".

# No USB scanners found. If you expected something different, make sure
that
# you have loaded a kernel driver for your USB host controller and have
setup
# the USB system correctly. See man sane-usb for details.
/dev/parport0 is accessible
==> ieee1284_open
==> init_port
Got -7 from ppdev init
<== -7
<== -7 (propagated)
==> ieee1284_open
==> init_port
Got -7 from ppdev init
<== -7
<== -7 (propagated)
==> ieee1284_open
==> init_port
Got -7 from ppdev init
<== -7
<== -7 (propagated)
==> ieee1284_open
==> init_port
Got -7 from ppdev init
<== -7
<== -7 (propagated)
==> ieee1284_open
==> init_port
Got -7 from ppdev init
<== -7
<== -7 (propagated)
==> ieee1284_open
==> init_port
Got -7 from ppdev init
<== -7
<== -7 (propagated)

# No Mustek parallel port scanners found. If you expected something
# different, make sure the scanner is correctly connected to your
computer
# and you have apropriate access rights.

# Most Scanners connected to the parallel port or other proprietary
ports
# can't be detected by this program.

# You may want to run this program as root to find all devices. Once
you
# found the scanner devices, be sure to adjust access permissions as
# necessary.

Logged In: NO

I forgot to include an email address to contact me, so here you go:
philipp@sadleder.de