Brad Sawatzky <[EMAIL PROTECTED]> wrote: Hi,
Up to that point, you're seeing the preferences loading code setting options in a loop, resetting the options each time a reload is called for by the backend, except for the options that caused a reload. In that code, XSane is not yet taking memory references, and options are reloaded properly, so we mostly don't care about what's happening at that stage. (but ...) > Now the GUI is initialized and ready to go. I set a breakpoint on What's interesting is what happens in and around xsane_panel_build(), that effectively builds the options panels. Can you confirm that the issue happens only the first time you try to set the option? If that's the case, then the problem lies in XSane somewhere at startup, between the preferences loading and the building of the options panels. Also, could you try with another frontend? Preferably a frontend that doesn't share code with XSane/xscanimage. Quiteinsane maybe? Disabling the preferences loading in the XSane code would also be interesting. An XSane run with libsane 1.0.19-12 would be interesting too. That version has a fix in the net backend that now returns SANE_STATUS_INVAL in sane_control_option() if the options have not been reloaded by the frontend. XSane looks safe in this regard, so it should not trigger. I still don't know where the bug lies, but it could very well be in XSane after all. That's 50/50 so far. Thanks, JB. -- Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
