[sane] Mitsubishi Diamond View DV650U

I have a Mitsubishi Diamond View DV 650U scanner which I did not use much, so I am considering selling it. In order to test whether it is still functional and capability of working with linux, I use my RHEL5 to test that, and it works!

Install instruction:

1. yum install sane-backends sane-backends-libs xsane
2. Scanner firmware is also needed, You can find it at driver CD, namely, u176v042.bin. You can also download from http://www.mitsubishielectric.com.au/420.htm
3. copy the firmware file as /usr/share/sane/snapsane/your-firmwarefile.bin (Yes, I am too lazy to modify the /etc/sane.d/snapsane.conf).
4. Plug out the scanner’s power and USB.
5. Plug back scanner’s power and USB.
6. See whether your scanner is detected with sane-find-scanner, It should be recognized as ACER flatbed scanner.
7. See whether the scanner is detected with scanimage -L.
   if not, go back to 4.

8. Test with xsane, it should work at this point. If not:
9. redo step 4 to 7.
10. export SANE_DEBUG_SNAPSCAN=10
11. scanimage -d snapscan:libusb:xxx:yyy -x 50 -y 50 –format=tiff > ./test1.tiff
    (xxx and yyy are 3-digit integers and from step 7).

12. See the debug message and retry.

Hope it is sufficient.

gprof works best with static link.

Some of my programs are extremely slow, so I try to use gprof to profile them.
After several test run, only the functions in the executable are profiled but not those from the shared library even both are complied with “-pg”.

HP gprof man mentions that environment LD_PROFILE can be set, it does reveal more functions in fedora, but not in the way I want.

Finally, I found this blog:
http://hi.baidu.com/yesbaba/blog/item/016ccc4ba78d23f482025cb6.html
and link my programs statically and voila, it works!

The underscore prefix cannot be used in t_n (2nd) parameter of G_DEFINE_TYPE.

While debuging tomoe, the original code in lib/tomoe-dict-ptr-array.c reads:

G_DEFINE_ABSTRACT_TYPE (TomoeDictPtrArray, _tomoe_dict_ptr_array, TOMOE_TYPE_DICT)

But it does not work and cause segmentation fault in scim-tomoe.

After remove the _ from the 2nd parameter (and corresponding functions),
it works like charm.

Keyboard Layout Taxonomy Proposal

Currently the keyboard layout is categorized by countries, which might not be suitable because it may bring following issues:

1. Country flags (which may cause political problems)
2. Not fair for the countries which are not in the list, e.g. Australia, New Zealand, Singapore, etc…
3. Some layout is also available in certain countries but not recognized, e.g. Dvorak in China and India.
4. Produce redundancy, like QWERTY in US, CN, IN are actually the same, but need to list 3 times.

Proposed Keyboard Layout Taxonomy

Use the keyboard layout itself as categories, such like:

1. QWERTY– Default
   • ja_JP
   • ko_KR
   • de_CH
   • fr_CH
   • it_CH
   • en_UK
   • …
2. DVORAK
   • @lefthand
   • @righthand
3. QWERTZ
   • de_CH
     • @SunDeadKey
     • @NOSunDeadKey
     • @Mac
   • fr_CH
   • it_CH
   • …
4. AZERTY
   • fr_FR
   • fr_BE

This taxonomy is more concise than countries-oriented. Users do not need to scroll the long countries list; and input method developers can easily have brief idea that what are they going to deal with.