Re: Check device use before detaching?

2013-11-28 Thread Michael Grzeschik
On Mon, Nov 18, 2013 at 08:19:38PM +, Luke-Jr wrote:
 My software does not interface with keyboards under any condition.
 
 Some specific devices I'm working with include:
 FTDI: Avalon, Butterfly Labs BitFORCE  BitFORCE SC, The Chili
 CP210X: Bitfountain Block Erupter Emerald/Sapphire
 CDC/ACM: Big Picture Mining, BTCFPGA ModMiner
 PL2303: Icarus

So you somehow got into a goldrush here! :)

The software will probably be an daemon that will guarantee that thos
gold-diggers are working 24/7? If so, I think the manufacturers of the
devices did choose the wrong interface then.

Regards,
Michael

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Check device use before detaching?

2013-11-18 Thread Greg KH
On Mon, Nov 18, 2013 at 07:10:45AM +, Luke-Jr wrote:
 On Monday, November 18, 2013 6:07:37 AM Greg KH wrote:
   I want my software to ignore devices that are already in use by other
   software. The other software might be accessing it via the kernel
   drivers, or perhaps libusb. My software (in this case) would be using
   libusb, and need to detach the kernel drivers to claim the interface -
   even if the kernel driver isn't currently in use.
  
  What types of devices?
 
 Just tty/serial devices (HID, VCOM, and CDC/ACM)

HID devices are not tty/serial devices, so I'm confused as to what you
want to do with them.

  And no, there is no general way to determine this, sorry, it all
  depends on the type of device, and for some of them, you really can't
  tell (think about a keyboard, when is it in use?)
 
 When X has it open?

X opens all input devices all the time, it never closes them.

   So, I want to detach the driver so I can use it myself, but only if some
   other software isn't already using it.
  
  What will you do with the device?
 
 Send it work to process, and get results back.

What type of work can you send a keyboard?

And why not just use the kernel interfaces to the device?  That way you
know it works properly with anything else that has opened it at the
time.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Check device use before detaching?

2013-11-18 Thread Alan Stern
On Mon, 18 Nov 2013, Luke-Jr wrote:

 Is there a way to tell if a USB device is in use or not before requesting the 
 kernel detach drivers?
 
 I'd define in use as either an interface claimed on usbfs or tty/etc 
 provided by a kernel driver being opened. And not in use including kernel 
 driver attached, but not interfacing device to any software.

There is a form of the detach-driver call in usbfs that will not do 
anything if the current driver is usbfs.  But there is no way to tell 
if a tty or other device file is open, or if the device is interfaced 
to any software.

Alan Stern

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Check device use before detaching?

2013-11-18 Thread Luke-Jr
On Monday, November 18, 2013 1:37:23 PM Greg KH wrote:
 On Mon, Nov 18, 2013 at 07:10:45AM +, Luke-Jr wrote:
  On Monday, November 18, 2013 6:07:37 AM Greg KH wrote:
I want my software to ignore devices that are already in use by other
software. The other software might be accessing it via the kernel
drivers, or perhaps libusb. My software (in this case) would be using
libusb, and need to detach the kernel drivers to claim the interface
- even if the kernel driver isn't currently in use.
   
   What types of devices?
  
  Just tty/serial devices (HID, VCOM, and CDC/ACM)
 
 HID devices are not tty/serial devices, so I'm confused as to what you
 want to do with them.

Ok, but they are still opened and closed.

   And no, there is no general way to determine this, sorry, it all
   depends on the type of device, and for some of them, you really can't
   tell (think about a keyboard, when is it in use?)
  
  When X has it open?
 
 X opens all input devices all the time, it never closes them.

Yes, I expect a keyboard would always be considered in use when X is running - 
perhaps even when it isn't, if it's used by virtual consoles.

So, I want to detach the driver so I can use it myself, but only if
some other software isn't already using it.
   
   What will you do with the device?
  
  Send it work to process, and get results back.
 
 What type of work can you send a keyboard?

My software does not interface with keyboards under any condition.

Some specific devices I'm working with include:
FTDI: Avalon, Butterfly Labs BitFORCE  BitFORCE SC, The Chili
CP210X: Bitfountain Block Erupter Emerald/Sapphire
CDC/ACM: Big Picture Mining, BTCFPGA ModMiner
PL2303: Icarus

 And why not just use the kernel interfaces to the device?  That way you
 know it works properly with anything else that has opened it at the
 time.

I do, when permissions are set such that I can. Unfortunately, the current 
Gentoo-stable eudev does not give any groups access to hidraw devices, so it 
fails over to libusb.

Luke
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Check device use before detaching?

2013-11-18 Thread Greg KH
On Mon, Nov 18, 2013 at 08:19:38PM +, Luke-Jr wrote:
 My software does not interface with keyboards under any condition.
 
 Some specific devices I'm working with include:
 FTDI: Avalon, Butterfly Labs BitFORCE  BitFORCE SC, The Chili
 CP210X: Bitfountain Block Erupter Emerald/Sapphire
 CDC/ACM: Big Picture Mining, BTCFPGA ModMiner
 PL2303: Icarus

How can you control them through libusb?  Why not just use the tty
device the kernel exports for you?

  And why not just use the kernel interfaces to the device?  That way you
  know it works properly with anything else that has opened it at the
  time.
 
 I do, when permissions are set such that I can. Unfortunately, the current 
 Gentoo-stable eudev does not give any groups access to hidraw devices, so it 
 fails over to libusb.

Then fix that by using console-kit to set the permissions of the devices
that the local user has access to.

best of luck,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Check device use before detaching?

2013-11-18 Thread Luke-Jr
On Monday, November 18, 2013 8:29:24 PM Greg KH wrote:
 On Mon, Nov 18, 2013 at 08:19:38PM +, Luke-Jr wrote:
  My software does not interface with keyboards under any condition.
  
  Some specific devices I'm working with include:
  FTDI: Avalon, Butterfly Labs BitFORCE  BitFORCE SC, The Chili
  CP210X: Bitfountain Block Erupter Emerald/Sapphire
  CDC/ACM: Big Picture Mining, BTCFPGA ModMiner
  PL2303: Icarus
 
 How can you control them through libusb?  Why not just use the tty
 device the kernel exports for you?

Right, I got distracted writing this part. I'm only really using libusb as a 
fallback for HID devices (since hidapi has support already)...
HID: NanoFury and HashBuster nano

   And why not just use the kernel interfaces to the device?  That way you
   know it works properly with anything else that has opened it at the
   time.
  
  I do, when permissions are set such that I can. Unfortunately, the
  current Gentoo-stable eudev does not give any groups access to hidraw
  devices, so it fails over to libusb.
 
 Then fix that by using console-kit to set the permissions of the devices
 that the local user has access to.

Often there is no local user on these systems.

Luke
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Check device use before detaching?

2013-11-18 Thread Greg KH
On Mon, Nov 18, 2013 at 08:38:39PM +, Luke-Jr wrote:
 On Monday, November 18, 2013 8:29:24 PM Greg KH wrote:
  On Mon, Nov 18, 2013 at 08:19:38PM +, Luke-Jr wrote:
   My software does not interface with keyboards under any condition.
   
   Some specific devices I'm working with include:
   FTDI: Avalon, Butterfly Labs BitFORCE  BitFORCE SC, The Chili
   CP210X: Bitfountain Block Erupter Emerald/Sapphire
   CDC/ACM: Big Picture Mining, BTCFPGA ModMiner
   PL2303: Icarus
  
  How can you control them through libusb?  Why not just use the tty
  device the kernel exports for you?
 
 Right, I got distracted writing this part. I'm only really using libusb as a 
 fallback for HID devices (since hidapi has support already)...
 HID: NanoFury and HashBuster nano

Ok, this is making no sense.  As you really aren't saying exactly what
you are trying to do, I'm going to just give up and say you can't do it.

good luck,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Check device use before detaching?

2013-11-18 Thread Luke-Jr
On Monday, November 18, 2013 9:25:49 PM Greg KH wrote:
 Ok, this is making no sense.  As you really aren't saying exactly what
 you are trying to do, I'm going to just give up and say you can't do it.

As I said before, I want to use devices only if they aren't already in use.
With hidapi's hidraw implementation, I'm pretty sure this works fine. But when 
failing over to hidapi's libusb implementation it always needs to interrupt 
other software since there is no way to determine if it's in use or not.

Luke
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Check device use before detaching?

2013-11-17 Thread Luke-Jr
Is there a way to tell if a USB device is in use or not before requesting the 
kernel detach drivers?

I'd define in use as either an interface claimed on usbfs or tty/etc 
provided by a kernel driver being opened. And not in use including kernel 
driver attached, but not interfacing device to any software.

Thoughts?

Luke
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Check device use before detaching?

2013-11-17 Thread Greg KH
On Mon, Nov 18, 2013 at 01:44:19AM +, Luke-Jr wrote:
 Is there a way to tell if a USB device is in use or not before requesting the 
 kernel detach drivers?

Not really, sorry.

 I'd define in use as either an interface claimed on usbfs or tty/etc 
 provided by a kernel driver being opened. And not in use including kernel 
 driver attached, but not interfacing device to any software.
 
 Thoughts?

You might want to find a way, but think about a user removing a device
at any point in time.  Drivers have to handle this already, so it really
doesn't make sense to have this type of functionality if it can't be
used by anyone.

What problem are you trying to solve?

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Check device use before detaching?

2013-11-17 Thread Luke-Jr
On Monday, November 18, 2013 4:40:55 AM Greg KH wrote:
 On Mon, Nov 18, 2013 at 01:44:19AM +, Luke-Jr wrote:
  Is there a way to tell if a USB device is in use or not before requesting
  the kernel detach drivers?
 
 Not really, sorry.
 
  I'd define in use as either an interface claimed on usbfs or tty/etc
  provided by a kernel driver being opened. And not in use including
  kernel driver attached, but not interfacing device to any software.
  
  Thoughts?
 
 You might want to find a way, but think about a user removing a device
 at any point in time.  Drivers have to handle this already, so it really
 doesn't make sense to have this type of functionality if it can't be
 used by anyone.
 
 What problem are you trying to solve?

I want my software to ignore devices that are already in use by other 
software. The other software might be accessing it via the kernel drivers, 
or perhaps libusb. My software (in this case) would be using libusb, and need 
to detach the kernel drivers to claim the interface - even if the kernel 
driver isn't currently in use.

So, I want to detach the driver so I can use it myself, but only if some other 
software isn't already using it.

Luke
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Check device use before detaching?

2013-11-17 Thread Greg KH
On Mon, Nov 18, 2013 at 05:35:53AM +, Luke-Jr wrote:
 On Monday, November 18, 2013 4:40:55 AM Greg KH wrote:
  On Mon, Nov 18, 2013 at 01:44:19AM +, Luke-Jr wrote:
   Is there a way to tell if a USB device is in use or not before requesting
   the kernel detach drivers?
  
  Not really, sorry.
  
   I'd define in use as either an interface claimed on usbfs or tty/etc
   provided by a kernel driver being opened. And not in use including
   kernel driver attached, but not interfacing device to any software.
   
   Thoughts?
  
  You might want to find a way, but think about a user removing a device
  at any point in time.  Drivers have to handle this already, so it really
  doesn't make sense to have this type of functionality if it can't be
  used by anyone.
  
  What problem are you trying to solve?
 
 I want my software to ignore devices that are already in use by other 
 software. The other software might be accessing it via the kernel drivers, 
 or perhaps libusb. My software (in this case) would be using libusb, and need 
 to detach the kernel drivers to claim the interface - even if the kernel 
 driver isn't currently in use.

What types of devices?

And no, there is no general way to determine this, sorry, it all
depends on the type of device, and for some of them, you really can't
tell (think about a keyboard, when is it in use?)

 So, I want to detach the driver so I can use it myself, but only if some 
 other 
 software isn't already using it.

What will you do with the device?  Why not just have the user tell you
which device you want to claim?

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Check device use before detaching?

2013-11-17 Thread Luke-Jr
On Monday, November 18, 2013 6:07:37 AM Greg KH wrote:
  I want my software to ignore devices that are already in use by other
  software. The other software might be accessing it via the kernel
  drivers, or perhaps libusb. My software (in this case) would be using
  libusb, and need to detach the kernel drivers to claim the interface -
  even if the kernel driver isn't currently in use.
 
 What types of devices?

Just tty/serial devices (HID, VCOM, and CDC/ACM)

 And no, there is no general way to determine this, sorry, it all
 depends on the type of device, and for some of them, you really can't
 tell (think about a keyboard, when is it in use?)

When X has it open?

  So, I want to detach the driver so I can use it myself, but only if some
  other software isn't already using it.
 
 What will you do with the device?

Send it work to process, and get results back.

 Why not just have the user tell you which device you want to claim?

They can do that, but users like automatic stuff by default :/

Luke
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html