On Thu, 10 Jul 2008, Julien BLACHE wrote:

> Brad Sawatzky <[EMAIL PROTECTED]> wrote:
> 
> > b) The pointer in the menu.label for the active source menu (in this case)
> >    is not being kept current.
> >    - FIX: Recreate/update the gtk menu and do a panel_rebuild every time
> >      the net backend changes the NON-local opt array (since that is the
> >      memory referenced by the pointer stored in menu.label.
> 
> The panel should be rebuilt every time the backend asks for the
> options to be reloaded. A look at the XSane sources suggests that it's
> being done, but it looks like there's a corner case somewhere.

I guess I wasn't clear.  Right now, no matter when the panel is built, the
Source menu will contain references to memory that can and will be
deallocated as sanei_ communicates over the network.  The data in those
references are not stored in any local copy of the opt list.

AFAICT, the fact that the Source menu for other backends work at all over
the netowrk is simply due to good fortune.

The Resolution menu is already treated differently and stores local copies
of the data which is why it works while Source doesn't.

> As far as I could see, the info output parameter is checked and
> honoured for every SET_VALUE call.
> 
> As I cannot reproduce the problem with the hardware I own, I can't
> debug this further.

I understand.  I've been looking for some insight into the code -- without
knowing what the code is supposed to do, I don't know how to fix it.  The
problem I've described occurs for all backends accessed over the net.  The
epson/epkowa backend just makes it visible to the user.

[ from earlier message ]
> > What is the intent of duplicating s->opt into s->local_opt?  If it is to
> > provide a stable local version of the scanner descriptors then shouldn't
>
> Per the SANE standard, the descriptors have to remain available at the
> same location until the device is closed. If it wasn't the case, it'd
> be a major pain for the frontends to keep track of the options. (it
> could be done with more API calls, though, but that's added complexity
> for no benefit)

Then the net backend is breaking the SANE standard.  s->local_opt.desc[] is
not a complete copy of the descriptors since memcpy merely duplicates the
pointer to the .constraint union member, but not the underlying data
(option (a) in the previous message).

PS: I worry I'm spamming bugs.debian.org with these details.  If I should
    be communicating directly with upstream please tell what is the best way to
    do that and I'll stop hassling you :-)

Thanks for you work,
-- Brad



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to