> > Well, actually no, they are not.
> > Working through usbdevfs is limited to usb obviously.
> > There are eg. cameras with both, usb and firewire.
>
> I thought this discussion was about scanners? :)
SANE is for cameras, too.
But, if you wish, there are firewire scanners.
And the problem is not limited to SANE.
> And it's not useful to criticise usb for having an
> API that firewire is missing ... again, that's less
> helpful than doing it the other way around.
Firewire has another API to do that.
What I am critical of is creating several APIs to do the same thing.
> > Secondly going through the device node is easier
>
> The usbdevfs nodes ARE device nodes! Your
Yes and no. They lack permissions.
Usbdevfs more or less forces you to use all the hotplugging support
infrastructure.
> (new) scenario was basically teaching specialized
> device drivers about things usbdevfs already knows.
> That means more specialized code in the kernel...
No, the character/block layer should know about that ioctl.
It's reducing the amount of specialised code.
The ordinary device driver would just have "usb_generic_type_reporting" in
its device structure.
> > With the current model I can do 'chmod 660 /dev/usbscanner0'
> > and the issue is settled. You can't beat that for simplicity ;-)
>
> The simplicity comes from having one device, not N.
> Given USB, I'd call that oversimplification.
It may or may not be oversimplification.
There are a lot of very simple systems out there, that have just one scanner
or printer permanently attached via USB. IMHO there is no sense to let them
install the full hotplugging support and configure it.
By the way "chmod 660 /dev/usbscanner*" works for many devices ;-)
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
