[sane-devel] Saned problem
On Sun, 2007-05-27 at 21:29 +0200, Jochen Eisinger wrote: Hi, what does the following command output as user: SANE_DEBUG_SANEI_USB=128 scanimage -L This is the result: [sanei_debug] Setting debug level of sanei_usb to 128. [sanei_usb] sanei_usb_init: Looking for kernel scanner devices [sanei_usb] sanei_usb_init: Looking for libusb devices usb_set_debug: Setting debugging level to 255 (on) usb_os_find_busses: Found 002 usb_os_find_busses: Found 001 usb_os_find_devices: couldn't get connect info usb_os_find_devices: Found 001 on 002 error obtaining child information: Operation not permitted usb_os_find_devices: couldn't get connect info usb_os_find_devices: Found 002 on 001 usb_os_find_devices: couldn't get connect info usb_os_find_devices: Found 001 on 001 error obtaining child information: Operation not permitted error obtaining child information: Operation not permitted [sanei_usb] sanei_usb_init: device 0x/0x looks like a root hub [sanei_usb] sanei_usb_init: found libusb device (0x04b8/0x080e) interface 0 at libusb:001:002 [sanei_usb] sanei_usb_init: device 0x/0x looks like a root hub [sanei_usb] sanei_usb_init: found 1 devices [sanei_usb] sanei_usb_find_devices: vendor=0x1606, product=0x0010 [sanei_usb] sanei_usb_find_devices: vendor=0x1606, product=0x0030 [sanei_usb] sanei_usb_find_devices: vendor=0x1606, product=0x0130 [sanei_debug] Setting debug level of sanei_usb to 128. [sanei_usb] sanei_usb_init: Looking for kernel scanner devices [sanei_usb] sanei_usb_init: Looking for libusb devices usb_os_init: Found USB VFS at /dev/bus/usb usb_set_debug: Setting debugging level to 255 (on) [sanei_usb] sanei_usb_init: device 0x/0x looks like a root hub [sanei_usb] sanei_usb_init: found libusb device (0x04b8/0x080e) interface 0 at libusb:001:002 [sanei_usb] sanei_usb_init: device 0x/0x looks like a root hub [sanei_usb] sanei_usb_init: found 1 devices [sanei_usb] sanei_usb_find_devices: vendor=0x1606, product=0x0230 [sanei_usb] sanei_usb_open: trying to open device `/dev/usbscanner' [sanei_usb] sanei_usb_open: can't find device `/dev/usbscanner' in list [sanei_debug] Setting debug level of sanei_usb to 128. [sanei_usb] sanei_usb_init: Looking for kernel scanner devices [sanei_usb] sanei_usb_init: Looking for libusb devices usb_os_init: Found USB VFS at /dev/bus/usb usb_set_debug: Setting debugging level to 255 (on) [sanei_usb] sanei_usb_init: device 0x/0x looks like a root hub [sanei_usb] sanei_usb_init: found libusb device (0x04b8/0x080e) interface 0 at libusb:001:002 [sanei_usb] sanei_usb_init: device 0x/0x looks like a root hub [sanei_usb] sanei_usb_init: found 1 devices [sanei_usb] sanei_usb_find_devices: vendor=0x07b3, product=0x0001 [sanei_usb] sanei_usb_find_devices: vendor=0x0458, product=0x2004 [sanei_debug] Setting debug level of sanei_usb to 128. [sanei_usb] sanei_usb_init: Looking for kernel scanner devices [sanei_usb] sanei_usb_init: Looking for libusb devices usb_os_init: Found USB VFS at /dev/bus/usb usb_set_debug: Setting debugging level to 255 (on) [sanei_usb] sanei_usb_init: device 0x/0x looks like a root hub [sanei_usb] sanei_usb_init: found libusb device (0x04b8/0x080e) interface 0 at libusb:001:002 [sanei_usb] sanei_usb_init: device 0x/0x looks like a root hub [sanei_usb] sanei_usb_init: found 1 devices [sanei_usb] sanei_usb_find_devices: vendor=0x04a5, product=0x1a20 [sanei_usb] sanei_usb_find_devices: vendor=0x04a5, product=0x1a26 [sanei_usb] sanei_usb_find_devices: vendor=0x04a5, product=0x2022 [sanei_usb] sanei_usb_find_devices: vendor=0x04a5, product=0x1a2a [sanei_usb] sanei_usb_find_devices: vendor=0x04a5, product=0x2040 [sanei_usb] sanei_usb_find_devices: vendor=0x04a5, product=0x2060 [sanei_usb] sanei_usb_find_devices: vendor=0x04a5, product=0x207e [sanei_usb] sanei_usb_find_devices: vendor=0x04a5, product=0x20be [sanei_usb] sanei_usb_find_devices: vendor=0x04a5, product=0x20c0 [sanei_usb] sanei_usb_find_devices: vendor=0x04a5, product=0x20b0 [sanei_usb] sanei_usb_find_devices: vendor=0x04a5, product=0x20de [sanei_usb] sanei_usb_find_devices: vendor=0x04a5, product=0x20f8 [sanei_usb] sanei_usb_find_devices: vendor=0x04a5, product=0x20fc [sanei_usb] sanei_usb_find_devices: vendor=0x04a5, product=0x20fe [sanei_usb] sanei_usb_find_devices: vendor=0x04a5, product=0x2137 [sanei_usb] sanei_usb_find_devices: vendor=0x06bd, product=0x0002 [sanei_usb] sanei_usb_find_devices: vendor=0x06bd, product=0x0001 [sanei_usb] sanei_usb_find_devices: vendor=0x06bd, product=0x2061 [sanei_usb] sanei_usb_find_devices: vendor=0x06bd, product=0x2093 [sanei_usb] sanei_usb_find_devices: vendor=0x06bd, product=0x2091 [sanei_usb] sanei_usb_find_devices: vendor=0x06bd, product=0x2095 [sanei_usb] sanei_usb_find_devices: vendor=0x06bd, product=0x2097 [sanei_usb] sanei_usb_find_devices: vendor=0x06bd, product=0x208d [sanei_usb] sanei_usb_find_devices: vendor=0x06bd, product=0x20ff [sanei_usb] sanei_usb_find_devices: vendor=0x06bd,
[sane-devel] Formulardaten
=== == Neuer Eintrag === --- -- Formular: 'adddev' --- 1. Your email address: 'dmakovey at yahoo.com' 2. Manufacturer (e.g. Mustek): 'Primax Electronics, Ltd Visioneer ' 3. Model name (e.g. ScanExpress 1200UB): 'Onetouch 8920 Scanner' 4. Bus type: 'USB' 5. Vendor id (e.g. 0x001): '0x0461' 6. Product id (e.g. 0x0002): '0x0371' 7. Chipset (e.g. lm9831): '' 8. Comments (e.g. similar to Mustek 1234): 'output from /proc/bus/usb/devices: T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0461 ProdID=0371 Rev= 1.00 S: Manufacturer=Primax S: Product=USB Scanner S: SerialNumber=RTS8801C2-004 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=ff Driver=(none) E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 8 Ivl=0ms E: Ad=83(I) Atr=03(Int.) MxPS= 1 Ivl=250ms ' 9. Data (e.g. sane-find-scanner -v -v): 'This is sane-find-scanner from sane-backends 1.0.18 # 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. searching for SCSI scanners: checking /dev/scanner... failed to open (Invalid argument) checking /dev/sg0... failed to open (Invalid argument) checking /dev/sg1... failed to open (Invalid argument) checking /dev/sg2... failed to open (Invalid argument) checking /dev/sg3... failed to open (Invalid argument) checking /dev/sg4... failed to open (Invalid argument) checking /dev/sg5... failed to open (Invalid argument) checking /dev/sg6... failed to open (Invalid argument) checking /dev/sg7... failed to open (Invalid argument) checking /dev/sg8... failed to open (Invalid argument) checking /dev/sg9... failed to open (Invalid argument) checking /dev/sga... failed to open (Invalid argument) checking /dev/sgb... failed to open (Invalid argument) checking /dev/sgc... failed to open (Invalid argument) checking /dev/sgd... failed to open (Invalid argument) checking /dev/sge... failed to open (Invalid argument) checking /dev/sgf... failed to open (Invalid argument) checking /dev/sgg... failed to open (Invalid argument) checking /dev/sgh... failed to open (Invalid argument) checking /dev/sgi... failed to open (Invalid argument) checking /dev/sgj... failed to open (Invalid argument) checking /dev/sgk... failed to open (Invalid argument) checking /dev/sgl... failed to open (Invalid argument) checking /dev/sgm... failed to open (Invalid argument) checking /dev/sgn... failed to open (Invalid argument) checking /dev/sgo... failed to open (Invalid argument) checking /dev/sgp... failed to open (Invalid argument) checking /dev/sgq... failed to open (Invalid argument) checking /dev/sgr... failed to open (Invalid argument) checking /dev/sgs... failed to open (Invalid argument) checking /dev/sgt... failed to open (Invalid argument) checking /dev/sgu... failed to open (Invalid argument) checking /dev/sgv... failed to open (Invalid argument) checking /dev/sgw... failed to open (Invalid argument) checking /dev/sgx... failed to open (Invalid argument) checking /dev/sgy... failed to open (Invalid argument) checking /dev/sgz... failed to open (Invalid argument) # No SCSI scanners found. If you expected something different, make sure that # you have loaded a kernel SCSI driver for your SCSI adapter. searching for USB scanners: checking /dev/usb/scanner... failed to open (Invalid argument) checking /dev/usb/scanner0... failed to open (Invalid argument) checking /dev/usb/scanner1... failed to open (Invalid argument) checking /dev/usb/scanner2... failed to open (Invalid argument) checking /dev/usb/scanner3... failed to open (Invalid argument) checking /dev/usb/scanner4... failed to open (Invalid argument) checking /dev/usb/scanner5... failed to open (Invalid argument) checking /dev/usb/scanner5... failed to open (Invalid argument) checking /dev/usb/scanner7... failed to open (Invalid argument) checking /dev/usb/scanner8... failed to open (Invalid argument) checking /dev/usb/scanner9... failed to open (Invalid argument) checking /dev/usb/scanner10... failed to open (Invalid argument) checking /dev/usb/scanner11... failed to open (Invalid argument) checking /dev/usb/scanner12... failed to open (Invalid argument) checking /dev/usb/scanner13... failed to open (Invalid argument) checking /dev/usb/scanner14... failed to open (Invalid argument) checking /dev/usb/scanner15... failed to open (Invalid argument) checking /dev/usbscanner... failed to open (Invalid argument) checking /dev/usbscanner0... failed to open (Invalid argument) checking /dev/usbscanner1... failed to open (Invalid argument) checking /dev/usbscanner2... failed to open (Invalid
[sane-devel] Saned problem
Hi, what does ls -l /dev/bus/usb/001/002 show? Assuming you don't have appropriate access rights to this device, does changing access rights help? regards -- jochen
[sane-devel] Additional frame types in Sane 1
Am Sonntag, den 27.05.2007, 14:08 -0400 schrieb m. allan noah: Well extending SANE1 will certainly start the new discussion about finishing SANE2 standard before starting - ACK ;) But as we did not move forward and scanner support for Linux is more or less stopped in its development, I vote for extending SANE1. As long as it won't hurt the API and the flow-control, introducing more frametypes should be no problem... Nice to see no big flamewar about the simple frametype addition :-)! It really is nice that no flamewar starts here but I do not support to extend SANE1 this way. (see my following comment) SANE_FRAME_RGB,/* pixel-interleaved red/green/blue bands */ SANE_FRAME_RED,/* red band only */ SANE_FRAME_GREEN, /* green band only */ -SANE_FRAME_BLUE/* blue band only */ +SANE_FRAME_BLUE, /* blue band only */ +SANE_FRAME_INFRARED, /* infra-red band */ +SANE_FRAME_RGBI, /* pixel-interleaved red/green/blue/infra-red */ +SANE_FRAME_JPEG/* Joint Photographic Experts Group's JPEG */ } SANE_Frame; In the meantime I noticed the device can send Gray+IR as well which would mean SANE_FRAME_GRAYI, as well. i know you probably get RGBIRGBI... from the scanner, but for backwards compatability and to avoid the proliferation of frametypes- i propose to ONLY add SANE_FRAME_IR. Then an existing backend can add IR support to any other frametype by sending an extra frame, and existing frontends can be told to ignore the IR frame, and keep using the gray/rgb frames. Although you do not change the function calls at the end you change the SANE API, a frontend that shall handle this needs a lot of changes, also a backend needs a lot of changes. A new backend will not work properly with an old frontend. I suggest to do all this in SANE2 because it is incompatible to SANE1. In the moment a frontend has to handle 3 modes: GRAY RGB RGB 3-pass With the new suggestions it would have to handle GRAY RGB RGB 3pass GRAY + INFRARED RGB + INFRARED RGB 3pass + INFRARED RGBI JPEG + INFRARED? RED + INFRARED? etc. The change of the transmission format hast been put into SANE2 because it changes a lot in the comunication for frontends and backends. Where is the advantage to put it into SANE1? You will get incompatibilities between frontends and backends and you slow down (if this is possible at all) the development of SANE2. Finish the SANE2 standard. That solves all problems. Oliver
[sane-devel] Additional frame types in Sane 1
On 5/28/07, Oliver Rauch Oliver.Rauch at rauch-domain.de wrote:
Am Sonntag, den 27.05.2007, 14:08 -0400 schrieb m. allan noah:
Well extending SANE1 will certainly start the new discussion
about finishing SANE2 standard before starting - ACK ;)
But as we did not move forward and scanner support for Linux
is more or less stopped in its development, I vote for
extending SANE1.
As long as it won't hurt the API and the flow-control, introducing
more frametypes should be no problem...
Nice to see no big flamewar about the simple frametype addition :-)!
It really is nice that no flamewar starts here but I do not support to
extend SANE1 this way.
(see my following comment)
SANE_FRAME_RGB,/* pixel-interleaved red/green/blue
bands */
SANE_FRAME_RED,/* red band only */
SANE_FRAME_GREEN, /* green band only */
-SANE_FRAME_BLUE/* blue band only */
+SANE_FRAME_BLUE, /* blue band only */
+SANE_FRAME_INFRARED, /* infra-red band */
+SANE_FRAME_RGBI, /* pixel-interleaved
red/green/blue/infra-red */
+SANE_FRAME_JPEG/* Joint Photographic Experts Group's
JPEG */
}
SANE_Frame;
In the meantime I noticed the device can send Gray+IR as well which
would mean SANE_FRAME_GRAYI, as well.
i know you probably get RGBIRGBI... from the scanner, but for
backwards compatability and to avoid the proliferation of frametypes-
i propose to ONLY add SANE_FRAME_IR. Then an existing backend can add
IR support to any other frametype by sending an extra frame, and
existing frontends can be told to ignore the IR frame, and keep using
the gray/rgb frames.
Although you do not change the function calls
at the end you change the SANE API, a frontend that shall handle this
needs a lot of changes, also a backend needs a lot of changes.
A new backend will not work properly with an old frontend.
yes- if a front-end does not have an else{} for unknown frametypes,
then undesired results will occur.
I suggest to do all this in SANE2 because it is incompatible to SANE1.
In the moment a frontend has to handle 3 modes:
GRAY
RGB
RGB 3-pass
With the new suggestions it would have to handle
GRAY
RGB
RGB 3pass
GRAY + INFRARED
RGB + INFRARED
RGB 3pass + INFRARED
RGBI
JPEG + INFRARED?
RED + INFRARED?
etc.
i specifically want to avoid RGBI, so think of it this way-
GRAY
RGB
RGB 3pass
Anything + IR
every frontend does not have to handle IR (some dont handle 3 pass rgb now), so:
case default
discard_frame();
where discard_frame() just reads til EOF on that frame, maybe with a
warning on stderr.
The change of the transmission format hast been put into SANE2
because it changes a lot in the comunication for frontends and backends.
i disagree with 'a lot', but yes, it is a change.
Where is the advantage to put it into SANE1?
You will get incompatibilities between frontends and backends and you
slow down (if this is possible at all) the development of SANE2.
It would be hard for sane2 development to get any slower :) The sane2
standard as of now, requires a fair number of changes to many places
in both front and back-ends, and so it is very difficult to get
started, and also very difficult to release anything with .2 soversion
until the end. there is potentially a long wait before there are many
backends or front-ends ported.
Finish the SANE2 standard. That solves all problems.
i wish to see sane2 as well, but i do not believe that there are huge
numbers of developers lurking on this mailing list, just waiting for
us to get started on sane2. perhaps i am wrong, but i am not sure we
have the critical mass required to start that project.
allan
--
The truth is an offense, but not a sin
[sane-devel] HP 2400, GL646 and genesys
Hi all, My scanner is not supported, but the support page http://www.sane-project.org/cgi-bin/driver.pl?manu=Hewlett +Packardmodel=2400 says GL646 based, to be added to genesys backend. If I understand correctly, this support has been added to the latest genesys backend. http://www.sane-project.org/man/sane-genesys.5.html Is there a way of telling sane to use the genesys backend for this scanner? Or if anyone else has any comments on this scanner, please let me know. Thanks and kind regards, Shug
[sane-devel] Saned problem
On 28 May 07, at 18:12, Jochen Eisinger wrote: Hi, what does ls -l /dev/bus/usb/001/002 show? $ ls -l /dev/bus/usb/001/002 crw-rw-r-- 1 root scanner 189, 1 2007-05-28 09:39 /dev/bus/usb/001/002 Assuming you don't have appropriate access rights to this device, does changing access rights help? I haven't tried changing access rights; what should I change it to? Printing to the same device works fine - so permissions seem basically OK. Wouter. regards -- jochen
[sane-devel] Saned problem
On 28 May 07, at 21:35, Jochen Eisinger wrote: Hi, Wouter van Marle wrote: $ ls -l /dev/bus/usb/001/002 crw-rw-r-- 1 root scanner 189, 1 2007-05-28 09:39 /dev/bus/usb/001/002 is your user in group scanner? I haven't tried changing access rights; what should I change it to? a+rw for example That did the trick... so easy if you think of it! Thanks for the help. I really didn't think that could be the problem - particularly as running 'saned -d' from the command line under my normal user account had no problems. It's no matter what weird. Wouter. Printing to the same device works fine - so permissions seem basically OK. printing is done over some other program (such as cupsd) which might run with root privileges. regards -- jochen
[sane-devel] Additional frame types in Sane 1
Hi, On Monday 28 May 2007 13:04:28 Oliver Rauch wrote: Am Sonntag, den 27.05.2007, 14:08 -0400 schrieb m. allan noah: Well extending SANE1 will certainly start the new discussion about finishing SANE2 standard before starting - ACK ;) But as we did not move forward and scanner support for Linux is more or less stopped in its development, I vote for extending SANE1. As long as it won't hurt the API and the flow-control, introducing more frametypes should be no problem... Nice to see no big flamewar about the simple frametype addition :-)! It really is nice that no flamewar starts here but I do not support to extend SANE1 this way. (see my following comment) SANE_FRAME_RGB,/* pixel-interleaved red/green/blue bands */ SANE_FRAME_RED,/* red band only */ SANE_FRAME_GREEN, /* green band only */ -SANE_FRAME_BLUE/* blue band only */ +SANE_FRAME_BLUE, /* blue band only */ +SANE_FRAME_INFRARED, /* infra-red band */ +SANE_FRAME_RGBI, /* pixel-interleaved red/green/blue/infra-red */ +SANE_FRAME_JPEG/* Joint Photographic Experts Group's JPEG */ } SANE_Frame; In the meantime I noticed the device can send Gray+IR as well which would mean SANE_FRAME_GRAYI, as well. i know you probably get RGBIRGBI... from the scanner, but for backwards compatability and to avoid the proliferation of frametypes- i propose to ONLY add SANE_FRAME_IR. Then an existing backend can add IR support to any other frametype by sending an extra frame, and existing frontends can be told to ignore the IR frame, and keep using the gray/rgb frames. Although you do not change the function calls at the end you change the SANE API, a frontend that shall handle this needs a lot of changes, also a backend needs a lot of changes. A new backend will not work properly with an old frontend. I suggest to do all this in SANE2 because it is incompatible to SANE1. In the moment a frontend has to handle 3 modes: GRAY RGB RGB 3-pass With the new suggestions it would have to handle GRAY RGB RGB 3pass GRAY + INFRARED RGB + INFRARED RGB 3pass + INFRARED RGBI JPEG + INFRARED? RED + INFRARED? etc. First of all most frontends do not even support the few FAME types we currently have. Second most frontends are so badly written they do not even support an unknown lenght at scan start, some just error out, even others pop up some warning that handheld devices would not supported. However, this tocally sucks for all document scanners and thus I think most backends currently fill out with white or simillar when the paper run out before the setup scan height is reached. The change of the transmission format hast been put into SANE2 because it changes a lot in the comunication for frontends and backends. However, SANE2 will not happen the next ten years. Some reason why this is so: - all the open source apps support SANE 1 already - most professionaly are glad to have SANE 1 custom applications running today. They do not want spend thousands of money just to jump on some SANE 2 wagon. - we are happy to have so many devices supported at all, support for most old devices will never show up in a totally redone from scratch SANE2. + a probably a lot more that currently does not come to mind How long do some discuss a possible SANE 2? Furtheremore when we do not get a more step by step future road going most big companies would rather go TWAIN 2.0 (for Linux) than some jeopardy from scrathc undertaking. Btw. the reason Linux is so successful is because it was not rewritten from scratch every 5 years, but gradually improved and cleaned up. Where is the advantage to put it into SANE1? To have proper support for the backends and the few frontends that need it tomorrow and not in 10 years? You will get incompatibilities between frontends and backends and you slow down (if this is possible at all) the development of SANE2. Yeah, if possible at all. Sane already has so many options that are unsupported by most frontends, yet another frametype will not matter much at all. If I feel like setting a bitdepth of 32 or 64 bits all frontends I saw so far will not handle this as well. Finish the SANE2 standard. That solves all problems. I stopped listening to the SANE 2 bla bla like 5 years ago when it became clear to me that the people talking about just want to talk and not code. Yours, -- Ren? Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name
[sane-devel] Additional frame types in Sane 1
Hi,
On Monday 28 May 2007 14:08:37 m. allan noah wrote:
On 5/28/07, Oliver Rauch Oliver.Rauch at rauch-domain.de wrote:
Am Sonntag, den 27.05.2007, 14:08 -0400 schrieb m. allan noah:
Well extending SANE1 will certainly start the new discussion
about finishing SANE2 standard before starting - ACK ;)
But as we did not move forward and scanner support for Linux
is more or less stopped in its development, I vote for
extending SANE1.
As long as it won't hurt the API and the flow-control, introducing
more frametypes should be no problem...
Nice to see no big flamewar about the simple frametype addition :-)!
It really is nice that no flamewar starts here but I do not support to
extend SANE1 this way.
(see my following comment)
SANE_FRAME_RGB,/* pixel-interleaved red/green/blue
bands */
SANE_FRAME_RED,/* red band only */
SANE_FRAME_GREEN, /* green band only */
-SANE_FRAME_BLUE/* blue band only */
+SANE_FRAME_BLUE, /* blue band only */
+SANE_FRAME_INFRARED, /* infra-red band */
+SANE_FRAME_RGBI, /* pixel-interleaved
red/green/blue/infra-red */
+SANE_FRAME_JPEG/* Joint Photographic Experts
Group's JPEG */
}
SANE_Frame;
In the meantime I noticed the device can send Gray+IR as well which
would mean SANE_FRAME_GRAYI, as well.
i know you probably get RGBIRGBI... from the scanner, but for
backwards compatability and to avoid the proliferation of frametypes-
i propose to ONLY add SANE_FRAME_IR. Then an existing backend can add
IR support to any other frametype by sending an extra frame, and
existing frontends can be told to ignore the IR frame, and keep using
the gray/rgb frames.
Although you do not change the function calls
at the end you change the SANE API, a frontend that shall handle this
needs a lot of changes, also a backend needs a lot of changes.
A new backend will not work properly with an old frontend.
yes- if a front-end does not have an else{} for unknown frametypes,
then undesired results will occur.
They should better handle it, either via the network or a buggy frontend
they can get a random frametype today.
I suggest to do all this in SANE2 because it is incompatible to SANE1.
In the moment a frontend has to handle 3 modes:
GRAY
RGB
RGB 3-pass
With the new suggestions it would have to handle
GRAY
RGB
RGB 3pass
GRAY + INFRARED
RGB + INFRARED
RGB 3pass + INFRARED
RGBI
JPEG + INFRARED?
RED + INFRARED?
etc.
i specifically want to avoid RGBI, so think of it this way-
GRAY
RGB
RGB 3pass
Anything + IR
every frontend does not have to handle IR (some dont handle 3 pass rgb now),
so:
case default
discard_frame();
where discard_frame() just reads til EOF on that frame, maybe with a
warning on stderr.
It is not practical to send the IR data at the end as additional frame, with
5400 optical dpi (in my case) it is no fun to buffer hundreds of MB of IR
data just in case.
The change of the transmission format hast been put into SANE2
because it changes a lot in the comunication for frontends and backends.
i disagree with 'a lot', but yes, it is a change.
I disagree as well, it's just another optional frametype and we need
soon not in years. The emphasis lies on optional, most frontends are
of little use for dia scanners anyway.
Where is the advantage to put it into SANE1?
You will get incompatibilities between frontends and backends and you
slow down (if this is possible at all) the development of SANE2.
It would be hard for sane2 development to get any slower :) The sane2
standard as of now, requires a fair number of changes to many places
:-)
in both front and back-ends, and so it is very difficult to get
started, and also very difficult to release anything with .2 soversion
until the end. there is potentially a long wait before there are many
backends or front-ends ported.
Finish the SANE2 standard. That solves all problems.
i wish to see sane2 as well, but i do not believe that there are huge
numbers of developers lurking on this mailing list, just waiting for
us to get started on sane2. perhaps i am wrong, but i am not sure we
have the critical mass required to start that project.
SANE 2 has way too many unnecessary changes just for the fun
of it. It would have been way more productive to gradually transform
the current SANE codebase step by step, with clear compatibility pathes,
maybe even mid-layer converters.
For me SANE 2 solves nothing, with the avision backend supporting
nearly 100 devices I only have more work to make sure they work
after a massive SANE transformation.
As we saw the last years a totally new scanning API for Un*x will go
unnoticed and unsupported.
--
Ren? Rebe - ExactCODE
[sane-devel] Additional frame types in Sane 1
Hi, As a frontend developer, i would really enjoy that SANE 2 get developped, especially for its larger amount of well-known options. However, i'm not agree with the curent handling of scanner button (as we discussed earlier). Regards, ?tienne -- verso l'Alto !
[sane-devel] Additional frame types in Sane 1
On 5/28/07, Ren? Rebe rene at exactcode.de wrote:
Hi,
On Monday 28 May 2007 14:08:37 m. allan noah wrote:
On 5/28/07, Oliver Rauch Oliver.Rauch at rauch-domain.de wrote:
Am Sonntag, den 27.05.2007, 14:08 -0400 schrieb m. allan noah:
Well extending SANE1 will certainly start the new discussion
about finishing SANE2 standard before starting - ACK ;)
But as we did not move forward and scanner support for Linux
is more or less stopped in its development, I vote for
extending SANE1.
As long as it won't hurt the API and the flow-control, introducing
more frametypes should be no problem...
Nice to see no big flamewar about the simple frametype addition :-)!
It really is nice that no flamewar starts here but I do not support to
extend SANE1 this way.
(see my following comment)
SANE_FRAME_RGB,/* pixel-interleaved
red/green/blue bands */
SANE_FRAME_RED,/* red band only */
SANE_FRAME_GREEN, /* green band only */
-SANE_FRAME_BLUE/* blue band only */
+SANE_FRAME_BLUE, /* blue band only */
+SANE_FRAME_INFRARED, /* infra-red band */
+SANE_FRAME_RGBI, /* pixel-interleaved
red/green/blue/infra-red */
+SANE_FRAME_JPEG/* Joint Photographic Experts
Group's JPEG */
}
SANE_Frame;
In the meantime I noticed the device can send Gray+IR as well which
would mean SANE_FRAME_GRAYI, as well.
i know you probably get RGBIRGBI... from the scanner, but for
backwards compatability and to avoid the proliferation of frametypes-
i propose to ONLY add SANE_FRAME_IR. Then an existing backend can add
IR support to any other frametype by sending an extra frame, and
existing frontends can be told to ignore the IR frame, and keep using
the gray/rgb frames.
Although you do not change the function calls
at the end you change the SANE API, a frontend that shall handle this
needs a lot of changes, also a backend needs a lot of changes.
A new backend will not work properly with an old frontend.
yes- if a front-end does not have an else{} for unknown frametypes,
then undesired results will occur.
They should better handle it, either via the network or a buggy frontend
they can get a random frametype today.
should, yes, but they dont. look at scanimage.c for instance.
I suggest to do all this in SANE2 because it is incompatible to SANE1.
In the moment a frontend has to handle 3 modes:
GRAY
RGB
RGB 3-pass
With the new suggestions it would have to handle
GRAY
RGB
RGB 3pass
GRAY + INFRARED
RGB + INFRARED
RGB 3pass + INFRARED
RGBI
JPEG + INFRARED?
RED + INFRARED?
etc.
i specifically want to avoid RGBI, so think of it this way-
GRAY
RGB
RGB 3pass
Anything + IR
every frontend does not have to handle IR (some dont handle 3 pass rgb
now), so:
case default
discard_frame();
where discard_frame() just reads til EOF on that frame, maybe with a
warning on stderr.
It is not practical to send the IR data at the end as additional frame, with
5400 optical dpi (in my case) it is no fun to buffer hundreds of MB of IR
data just in case.
what are you currently doing with the backside scan of a duplex adf
scanner? a 36x24mm 8bit 5400dpi is only 40 megs? even 16 bit IR at 80
megs is smaller than a 600 dpi 24bit rgb A4 (90+ megs), and you are
already buffering that somehow.
i want to cause as little headache for the frontend writers as
possible. that means they should be able to add a simple loop to eat
any frames they dont understand, rather than special handling for
RGBI.
The change of the transmission format hast been put into SANE2
because it changes a lot in the comunication for frontends and backends.
i disagree with 'a lot', but yes, it is a change.
I disagree as well, it's just another optional frametype and we need
soon not in years. The emphasis lies on optional, most frontends are
of little use for dia scanners anyway.
this is true, but dont forget that the discussion is not just about IR
channel, but also about other 'frames' that the backend might be able
to provide. jpeg, icc, etc.
Where is the advantage to put it into SANE1?
You will get incompatibilities between frontends and backends and you
slow down (if this is possible at all) the development of SANE2.
It would be hard for sane2 development to get any slower :) The sane2
standard as of now, requires a fair number of changes to many places
:-)
in both front and back-ends, and so it is very difficult to get
started, and also very difficult to release anything with .2 soversion
until the end. there is potentially a long wait before there are many
backends or front-ends ported.
Finish the SANE2
[sane-devel] Umax 2200 (SCSI) Scanner Buttons
On Mon, 2007-05-28 at 13:17 +0200, Oliver Rauch wrote:
Hello Roger,
there is no (working) support for the buttons in umax.c
To enable the output button 0 pressed etc, do
export SANE_DEBUG_UMAX=12
before you start the frontend.
I believe I already set this to max and saw nothing regarding the
buttons.
This is why I asked about debugging SCSI and getting verbose output with
SCSI. Even though I have selected verbose/debugging w/i the kernel, I
still can't set SCSI debugging via /proc
But I am not sure if you will see any of these information,
the routine is to output debug messages, not to find out
if the buttons have been pressed.
Well, at least I know the buttons aren't actually working, but it's nice
to at least see a template within the code. Anyways, still would like
to see if I can't get a memory address dumped from SCSI. From my
guessing, the UMAX scanner probably sends out a signal through the scsi
(and USB if connected), when a button is pressed.
Best regards
Oliver
Am Samstag, den 26.05.2007, 02:01 -0700 schrieb roger:
I see a bit of code which is supposedly specific to some umax
scanners.
How can I get scsi logging to dump everything? (I already have debug
for sg compiled into the kernel, but echo blah /proc/scsi/scsi
fails... and I'm not seeing any recent docs concerning scsi logging
since 2002.
(I'd like to see if I can't get the external buttons working also for
the Umax Astra 2200 via scsi.)
---Begin Snip of umax.c---
switch(sensekey)
...
case
0x09:
/* vendor specific */
if (asc == 0x00)
{
DBG(DBG_sense, - button protocoll\n);
if (ascq 1)
{
dev-button0_pressed = 1;
DBG(DBG_sense, - button 0 pressed\n);
}
if (ascq 2)
{
dev-button1_pressed = 1;
DBG(DBG_sense, - button 1 pressed\n);
}
if (ascq 4)
{
dev-button2_pressed = 1;
DBG(DBG_sense, - button 2 pressed\n);
}
return SANE_STATUS_GOOD;
---End Snip of umax.c---
--
Roger
http://www.eskimo.com/~roger/index.html
Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61
Sat May 26 02:01:12 PDT 2007
--
Roger
http://www.eskimo.com/~roger/index.html
Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61
Mon May 28 13:44:10 PDT 2007
