[sane-devel] infrared, SANE_FRAME_RGBA

[m. allan noah]

On Fri, 15 Dec 2006, Gerhard Jaeger wrote:

> 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.

i think 'zero' is a bit overstated. only during image aquisition would 
it appear 'frozen'.

A. there are so many backends that block, most interactive frontends 
should already thread/fork to deal with this.

B. dealing with children and installing signal handlers in the backend can 
interfere with the front-end, for those platforms that fork().

C. backends become harder to debug. given the large number of backends vs 
frontends, and the unmaintained status of many backends, anything that 
makes them smaller/easier is good, as it increases the chances of them 
getting fixed by a novice.

>
>> 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
>

suggestions for that?

allan

> - Gerhard
>
>
>

-- 
"so don't tell us it can't be done, putting down what you don't know.
money isn't our god, integrity will free our souls" - Max Cavalera