[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
Keith Abraham wrote: Hi Keith,
This is an avenue often overlooked. Whenever I buy new kit I try to ascertainThis seems increasingly common in USB for one, if you check the source code for the rt2x00 project (that i help on) then you find a increasing number of vendor and device ID's all for the same physical chip! Scanners as you pointed out also do this *a lot*.the chipset used eg. I had a Median scanner but no Linux driver.After a bit of investigation I discovered the scanner had an Artec chipset. So I set up Sane to use the Artec driver (plus a proprietary file from the WindowsCD supplied with the scanner) and the scanner worked perfectly.
A quick email to the developer explaining what I had achieved and how I did it probably helped no one but the info is on the website it anyone ever needs it.
No this is very useful, if your scanner had a different VID and PID then this can be added to the driver so in future someone can just plug in the scanner and it is recognised automatically. It is also very common to identify chipsets by USB VID and PID but some *very* naughty manufactures have not updated the PID for different devices so you end up having to try to load different drivers to determine exactly what chip set you have present,
Perhaps because my solution involved the use of a proprietary firmware file it doesn't fulfil Neil's high standards now there's another scanner which doesn'trequire Windows.
I don't object to firmware myself , that is binary code that must be uploaded to the external device and then executes on the external device, yes it would be very nice if firmware was open source as well but in many cases this is just not possible and the firmware contains some of the IPR of the company. Firmware is often used so that things can easily be adjusted after an IC has been created, if the manufactures were sure of a design and that it would not need to be upgraded in the future then they could just create an IC with all the required functionality and no firmware. The biggest problem with firmware is that it should be distributed separately to the driver and supplied with its own licence that permits redistribution. One other solution is to embed an eeprom in the device so that the device carries its own firmware but can be flash upgraded if required, this solves the firmware distribution problem.
Regards Robin - The Mailing List for the Devon & Cornwall LUG Mail majordomo@xxxxxxxxxxxxx with "unsubscribe list" in the message body to unsubscribe. FAQ: www.dcglug.org.uk/linux_adm/list-faq.html