Backend authors take note: sane-backends 1.0.20cvs updates

[m. allan noah-3]

Updates to prepare for 1.0.20 release included change to several backends:

* backend/canon_dr.c, backend/fujitsu.c: SANE_FRAME_JPEG
* backend/coolscan3.c: SANE_FRAME_RGBI
* backend/genesys_gl646.c, backend/genesys_gl841.c:
    STATUS_HW_LOCKED
* backend/rts8891.c: STATUS_WARMING_UP
* backend/pixma_io_sanei.c, backend/xerox_mfp.c:
    STATUS_HW_LOCKED & STATUS_WARMING_UP

The first two are mine, but the others need some checking by the
authors to make sure that all the required changes have been made.
Particularly coolscan3, which might need to have it's infrared option
disabled, and xerox_mfp which might need to handle the warming up
status?

Unfortunately, the recent alioth upgrade seems to have broken
web-based cvs diffs, so you will have to get the changes manually with
'cvs diff'

Thanks!

allan
--
"The truth is an offense, but not a sin"

--
sane-devel mailing list: sane-devel@...
http://lists.alioth.debian.org/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to sane-devel-request@...

[stef-22]

Le Sunday 12 April 2009 22:04:41 m. allan noah, vous avez écrit :
> Updates to prepare for 1.0.20 release included change to several backends:
>
> * backend/canon_dr.c, backend/fujitsu.c: SANE_FRAME_JPEG
> * backend/coolscan3.c: SANE_FRAME_RGBI
> * backend/genesys_gl646.c, backend/genesys_gl841.c:
>     STATUS_HW_LOCKED
> * backend/rts8891.c: STATUS_WARMING_UP

        I have looked into the diff for the rts8891 and gl646 parts. It seems fine.
I'll test them with real hardware this week.

> * backend/pixma_io_sanei.c, backend/xerox_mfp.c:
>     STATUS_HW_LOCKED & STATUS_WARMING_UP
>
> The first two are mine, but the others need some checking by the
> authors to make sure that all the required changes have been made.
> Particularly coolscan3, which might need to have it's infrared option
> disabled, and xerox_mfp which might need to handle the warming up
> status?
>
> Unfortunately, the recent alioth upgrade seems to have broken
> web-based cvs diffs, so you will have to get the changes manually with
> 'cvs diff'
>
> Thanks!
>
> allan

        You beat me on the backends I'm maintaining by a few hours.

        I have also updated the pnm test backend.

Regards,
        Stef



--
sane-devel mailing list: sane-devel@...
http://lists.alioth.debian.org/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to sane-devel-request@...

[m. allan noah-3]

On Mon, Apr 13, 2009 at 2:17 AM, stef <stef.dev@...> wrote:

> Le Sunday 12 April 2009 22:04:41 m. allan noah, vous avez écrit :
>> Updates to prepare for 1.0.20 release included change to several backends:
>>
>> * backend/canon_dr.c, backend/fujitsu.c: SANE_FRAME_JPEG
>> * backend/coolscan3.c: SANE_FRAME_RGBI
>> * backend/genesys_gl646.c, backend/genesys_gl841.c:
>>     STATUS_HW_LOCKED
>> * backend/rts8891.c: STATUS_WARMING_UP
>
>        I have looked into the diff for the rts8891 and gl646 parts. It seems fine.
> I'll test them with real hardware this week.
>
>> * backend/pixma_io_sanei.c, backend/xerox_mfp.c:
>>     STATUS_HW_LOCKED & STATUS_WARMING_UP
>>
>> The first two are mine, but the others need some checking by the
>> authors to make sure that all the required changes have been made.
>> Particularly coolscan3, which might need to have it's infrared option
>> disabled, and xerox_mfp which might need to handle the warming up
>> status?
>>
>> Unfortunately, the recent alioth upgrade seems to have broken
>> web-based cvs diffs, so you will have to get the changes manually with
>> 'cvs diff'
>>
>> Thanks!
>>
>> allan
>
>        You beat me on the backends I'm maintaining by a few hours.
>
>        I have also updated the pnm test backend.

Right- forgot that one. I really dislike messing with other authors
backends, but in this case the changes were pretty small, and time is
short, so I took the risk :)

Thanks also for working on the commit scripts, I've been too busy...

allan

--
"The truth is an offense, but not a sin"

--
sane-devel mailing list: sane-devel@...
http://lists.alioth.debian.org/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to sane-devel-request@...

[Alessandro Zummo]

On Sun, 12 Apr 2009 16:04:41 -0400
"m. allan noah" <kitno455@...> wrote:

>
> The first two are mine, but the others need some checking by the
> authors to make sure that all the required changes have been made.
> Particularly coolscan3, which might need to have it's infrared option
> disabled, and xerox_mfp which might need to handle the warming up
> status?

 Hi, disabled because RGBI is not yet supposed to be supported, right?
--

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it


--
sane-devel mailing list: sane-devel@...
http://lists.alioth.debian.org/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to sane-devel-request@...

[m. allan noah-3]

On Thu, Apr 16, 2009 at 8:38 AM, Alessandro Zummo
<azummo-lists@...> wrote:

> On Sun, 12 Apr 2009 16:04:41 -0400
> "m. allan noah" <kitno455@...> wrote:
>
>>
>> The first two are mine, but the others need some checking by the
>> authors to make sure that all the required changes have been made.
>> Particularly coolscan3, which might need to have it's infrared option
>> disabled, and xerox_mfp which might need to handle the warming up
>> status?
>
>  Hi, disabled because RGBI is not yet supposed to be supported, right?

Correct. We will re-open the discussion of the API changes after we
get 1.0.20 out the door. I suppose you could still send the RGBI data,
and tell the front-end that it gets more bytes per line than expected.
But that will make most front-ends choke, so it is a poor workaround.

allan

--
"The truth is an offense, but not a sin"

--
sane-devel mailing list: sane-devel@...
http://lists.alioth.debian.org/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to sane-devel-request@...

[Alessandro Zummo]

On Thu, 16 Apr 2009 08:45:47 -0400
"m. allan noah" <kitno455@...> wrote:

> >  Hi, disabled because RGBI is not yet supposed to be supported, right?  
>
> Correct. We will re-open the discussion of the API changes after we
> get 1.0.20 out the door. I suppose you could still send the RGBI data,
> and tell the front-end that it gets more bytes per line than expected.
> But that will make most front-ends choke, so it is a poor workaround.

 Did the last release had the rgbi output? if yes I would rather keep it

--

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it


--
sane-devel mailing list: sane-devel@...
http://lists.alioth.debian.org/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to sane-devel-request@...

[m. allan noah-3]

We have never changed the API. Those new frame types have never been
in a sane release.

allan

On Thu, Apr 16, 2009 at 10:56 AM, Alessandro Zummo
<azummo-lists@...> wrote:

> On Thu, 16 Apr 2009 08:45:47 -0400
> "m. allan noah" <kitno455@...> wrote:
>
>> >  Hi, disabled because RGBI is not yet supposed to be supported, right?
>>
>> Correct. We will re-open the discussion of the API changes after we
>> get 1.0.20 out the door. I suppose you could still send the RGBI data,
>> and tell the front-end that it gets more bytes per line than expected.
>> But that will make most front-ends choke, so it is a poor workaround.
>
>  Did the last release had the rgbi output? if yes I would rather keep it
>
> --
>
>  Best regards,
>
>  Alessandro Zummo,
>  Tower Technologies - Torino, Italy
>
>  http://www.towertech.it
>
>

--
"The truth is an offense, but not a sin"

--
sane-devel mailing list: sane-devel@...
http://lists.alioth.debian.org/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to sane-devel-request@...

[Alessandro Zummo]

On Thu, 16 Apr 2009 11:02:48 -0400
"m. allan noah" <kitno455@...> wrote:

> We have never changed the API. Those new frame types have never been
> in a sane release.

 ok. I've checked the code. There's an ifdef for the frame type,
 would you like me to completely remove the extra bytes (thus disabling
 the infrared option) ?

--

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it


--
sane-devel mailing list: sane-devel@...
http://lists.alioth.debian.org/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to sane-devel-request@...

[m. allan noah-3]

I think it makes sense to hide any options that would cause the user
to get corrupted data. So, if the machine can be told to not send IR,
then that should be the only choice. If the machine always returns the
IR channel, then you should probably remove those bytes. Can you do
that easily?

allan

On Thu, Apr 16, 2009 at 3:50 PM, Alessandro Zummo
<azummo-lists@...> wrote:

> On Thu, 16 Apr 2009 11:02:48 -0400
> "m. allan noah" <kitno455@...> wrote:
>
>> We have never changed the API. Those new frame types have never been
>> in a sane release.
>
>  ok. I've checked the code. There's an ifdef for the frame type,
>  would you like me to completely remove the extra bytes (thus disabling
>  the infrared option) ?
>
> --
>
>  Best regards,
>
>  Alessandro Zummo,
>  Tower Technologies - Torino, Italy
>
>  http://www.towertech.it
>
>

--
"The truth is an offense, but not a sin"

--
sane-devel mailing list: sane-devel@...
http://lists.alioth.debian.org/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to sane-devel-request@...

[Alessandro Zummo]

On Thu, 16 Apr 2009 15:55:49 -0400
"m. allan noah" <kitno455@...> wrote:

> I think it makes sense to hide any options that would cause the user
> to get corrupted data. So, if the machine can be told to not send IR,
> then that should be the only choice. If the machine always returns the
> IR channel, then you should probably remove those bytes. Can you do
> that easily?

 I can just disable the infrared option, it should do the job.

--

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it


--
sane-devel mailing list: sane-devel@...
http://lists.alioth.debian.org/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to sane-devel-request@...

[Alessandro Zummo]

On Thu, 16 Apr 2009 08:45:47 -0400
"m. allan noah" <kitno455@...> wrote:

> Correct. We will re-open the discussion of the API changes after we
> get 1.0.20 out the door. I suppose you could still send the RGBI data,
> and tell the front-end that it gets more bytes per line than expected.
> But that will make most front-ends choke, so it is a poor workaround.

 Here we go... 1.0.20 is way out of the door and it's time to reopen
 this 4 (?) years old discussion.

 We have the new frame types in sane.h but they're
 commented out... the question is...

 anyone is against removing that #if 0 ?


--

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it


--
sane-devel mailing list: sane-devel@...
http://lists.alioth.debian.org/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to sane-devel-request@...

[m. allan noah-3]

On Mon, Nov 2, 2009 at 4:56 AM, Alessandro Zummo
<azummo-lists@...> wrote:

> On Thu, 16 Apr 2009 08:45:47 -0400
> "m. allan noah" <kitno455@...> wrote:
>
>> Correct. We will re-open the discussion of the API changes after we
>> get 1.0.20 out the door. I suppose you could still send the RGBI data,
>> and tell the front-end that it gets more bytes per line than expected.
>> But that will make most front-ends choke, so it is a poor workaround.
>
>  Here we go... 1.0.20 is way out of the door and it's time to reopen
>  this 4 (?) years old discussion.
>
>  We have the new frame types in sane.h but they're
>  commented out... the question is...
>
>  anyone is against removing that #if 0 ?

A-

're-open the discussion' != 'remove the #if 0'

frankly, it is bad when we don't do frequent releases, and so we tell
users of new equipment that they have to build from git repo, but the
git repo uses a different API.

so- lets release current tree as 1.0.21 in one month. At the same
time, we finalize the 2.0 spec. If we keep it small, we can do a 2.0
release around Jan 1. I'm pretty busy, but if i can get some help we
can swing it.

i am sure sane 1.0.21 and sane 2.0.0 will have to live concurrently
for a little while, so we will have to keep that in mind.

comments?

allan
--
"The truth is an offense, but not a sin"

--
sane-devel mailing list: sane-devel@...
http://lists.alioth.debian.org/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to sane-devel-request@...

[Alessandro Zummo]

On Mon, 2 Nov 2009 08:25:03 -0500
"m. allan noah" <kitno455@...> wrote:

> On Mo
> >
> >  We have the new frame types in sane.h but they're
> >  commented out... the question is...
> >
> >  anyone is against removing that #if 0 ?
>
> A-
>
> 're-open the discussion' != 'remove the #if 0'

 ouch ;)


> so- lets release current tree as 1.0.21 in one month. At the same
> time, we finalize the 2.0 spec. If we keep it small, we can do a 2.0
> release around Jan 1. I'm pretty busy, but if i can get some help we
> can swing it.
>
> i am sure sane 1.0.21 and sane 2.0.0 will have to live concurrently
> for a little while, so we will have to keep that in mind.
>
> comments?

 I agree on the "keep it small" . and even smaller.

--

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it


--
sane-devel mailing list: sane-devel@...
http://lists.alioth.debian.org/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to sane-devel-request@...

[Louis Lagendijk]

> On Mon, Nov 2, 2009 at 4:56 AM, Alessandro Zummo
> <azummo-lists@...> wrote:
>> On Thu, 16 Apr 2009 08:45:47 -0400
>> "m. allan noah" <kitno455@...> wrote:

>
> 're-open the discussion' != 'remove the #if 0'
>
> frankly, it is bad when we don't do frequent releases, and so we tell
> users of new equipment that they have to build from git repo, but the
> git repo uses a different API.
>
> so- lets release current tree as 1.0.21 in one month. At the same
> time, we finalize the 2.0 spec. If we keep it small, we can do a 2.0
> release around Jan 1. I'm pretty busy, but if i can get some help we
> can swing it.
>

+1, the changes we have seen since the last release warrant another 1.x
release without API changes

> i am sure sane 1.0.21 and sane 2.0.0 will have to live concurrently
> for a little while, so we will have to keep that in mind.
>
> comments?
>
Do we have agreement on what changes we need to make to the API for 2.x?
How big will be the impact on the clients? Is this really big enough to
require a parallel support?  I would see a 1.0.21 as a bugfix release.
Would you want to add new scanners to the 1.0.x relase after 1.0.21? What
will be the maintenance policy?


Louis

--
sane-devel mailing list: sane-devel@...
http://lists.alioth.debian.org/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to sane-devel-request@...

[m. allan noah-3]

On Mon, Nov 2, 2009 at 10:05 AM,  <louis@...> wrote:

>> On Mon, Nov 2, 2009 at 4:56 AM, Alessandro Zummo
>> <azummo-lists@...> wrote:
>>> On Thu, 16 Apr 2009 08:45:47 -0400
>>> "m. allan noah" <kitno455@...> wrote:
>
>>
>> 're-open the discussion' != 'remove the #if 0'
>>
>> frankly, it is bad when we don't do frequent releases, and so we tell
>> users of new equipment that they have to build from git repo, but the
>> git repo uses a different API.
>>
>> so- lets release current tree as 1.0.21 in one month. At the same
>> time, we finalize the 2.0 spec. If we keep it small, we can do a 2.0
>> release around Jan 1. I'm pretty busy, but if i can get some help we
>> can swing it.
>>
> +1, the changes we have seen since the last release warrant another 1.x
> release without API changes
>
>> i am sure sane 1.0.21 and sane 2.0.0 will have to live concurrently
>> for a little while, so we will have to keep that in mind.
>>
>> comments?
>>
> Do we have agreement on what changes we need to make to the API for 2.x?

no

> How big will be the impact on the clients?

unknown, but hopefully small.

> Is this really big enough to
> require a parallel support?

I would prefer not to, but there are lots of private and custom
front-ends out there, which might take some time to change.

> I would see a 1.0.21 as a bugfix release.

Because we are always adding new scanners, we never make 'just' at
bugfix release.

> Would you want to add new scanners to the 1.0.x relase after 1.0.21? What
> will be the maintenance policy?

Undecided.

allan
--
"The truth is an offense, but not a sin"

--
sane-devel mailing list: sane-devel@...
http://lists.alioth.debian.org/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to sane-devel-request@...