>>>>> "Thomas" == Thomas Klose <thomas.klose@xxxxxxxxxxxxx> writes:
Thomas> Am Mittwoch, den 06.10.2010, 09:24 +0200 schrieb Thomas Jarosch:
>> On Tuesday, 5. October 2010 19:15:29 Thomas Klose wrote: > If I
>> understand right, your solution does not address this issues. It is >
>> just an opinion, but I think the only clean solution would be to
>> remove > this function call at all. If the user wants to detach a
>> driver, he > should do it by himself, e.g. by calling the usb_detach
>> function. For > convenience maybe helper functions
>> (ftdi_detach_sio(), > ftdi_detach_sio_desc(), et cetera) could be
>> implemented.
>>
>> Before the detach code was in place, I've received an email about
>> every week why their code was unable to open the FTDI device (which
>> was clearly listed by lsusb). I don't want to go back to that
>> again...
Thomas> I understand your point of view. However, this solution may even
Thomas> worsen the problem over time: If people are not forced to use
Thomas> proper VID/PIDs for their devices, they won't do it. They may
Thomas> not even be aware, there is an problem. This kind of approach
Thomas> can potentially lead to a very unpleasant situation. The ACPI
Thomas> hell which resulted from a similar work-around-attitude is one
Thomas> example.
Thomas K.,
many developpers here don't do commercial development, and they work on many
different projects. So applying for a different VID/PID for everybody is a
lot of work and FTDI will soon run out of numbers. With the API to open a
named device, people can live with the default VID/PID. In fact there is
often only a small task to be done with libftdi, the rest can be done with
ftdi_sio, so ftdi_sio would need to be loaded for the new VID/PID anyway.
--
Uwe Bonnes bon@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|