[sane-devel] infrared, SANE_FRAME_RGBA

[Gerhard Jaeger]

On Thursday 14 December 2006 21:18, m. allan noah wrote:
> On Thu, 14 Dec 2006, Giuseppe Sacco wrote:
> 
> > Hi Gerard and all SANE developers,
> >
> > Il giorno gio, 14/12/2006 alle 13.40 +0100, Gerhard Jaeger ha scritto:
> > [...]
> >> But I think you are right, we are moving into a dead-end. We have
> >> devices that are able to do much more than we are able to support
> >> with the SANE 1 standard AND we have a not yet finished (if finished
> >> ever) SANE 2 standard.
> >>
> >> I'd like to hear/read some more opinions on that.
> >> Any?
> 
> i would vote for re-openning the discussion of SANE2, and begin a project 
> to port a limited number of backends forward. use a whole new SONAME, such 
> that sane1 and 2 libs can co-exist for awhile. many backends will never be 
> ported to sane2, because the scanners have not been made in 10+ years, and 
> there is no-one to do it.
> 
> my personal list of things other folks have mentioned:
> 
> 1. i hate threading/forking in backends. it makes debugging a mess, and 
> there are plenty of non-interactive uses for sane that dont need it (the 
> single most popular front-end, scanimage, for one :) As per recent 
> discussions on this list, any frontend that cares about non-blocking, has 
> already implemented a threading solution to deal with all the backends 
> that block. lets drop the non-blocking functions.

okay - move that responsibility over to the frontends? Otherwise the 
responsiveness of i.e. XSane will decrease to zero.

> 2. network protocol overhaul- this keeps coming up, but i dont understand 
> it fully.

No idea about that, but I think there are others around.

> 3. stackable/modular compression libs- lots of scanners give back jpeg as 
> their native format, and we usually open it up to a huge pixmap, just to 
> hand to front-end. this is esp. noticable over saned. zlib, jpeg, what 
> else?

ACK.

> 4. inconsistent option names and arguments between backends.
> 5. inconsistent gamma/brightness/contrast implementations (sanei_gamma 
> i have been playing with here)
> 6. persistent device naming. none of this libusb:xxx stuff, i want 
> the backend to provide the name, using something like serial number, 
> rather than using the sanei_usb name.
> 7. inconsistent conf file layouts- i actually would like to see something 
> more like samba.conf, with [sections], etc.
> 8. inconsistent debug levels. not that big of a deal i guess. i would 
> rather that they were a bitmask instead of a linear progression.

Full ACK.

> 9. i HATE the frontends changing br-x/y and tl-x/y into t/b/l/r- i have a 
> front-end that takes cli args like scanimage, and i have to do the same 
> option manipulations so that users can use their scanimage commands in my 
> prog. it also means that my back-ends provided help text for those options 
> is not useful.
> 
> 10. button support. getting better, but not there yet.

ACK

11. Overhaul build system

- Gerhard