
Hello I made a new release of my usb library for high-level communication with usb devices from Haskell. See: http://hackage.haskell.org/package/usb-0.3 I made the following changes compared to the previous 0.2.0.1: - Moved the enumeration of usb devices in its own module: System.USB.Enumeration - Moved the device descriptor inside the device type so that you can retrieve it without doing IO, e.g: deviceDesc :: Device -> DeviceDesc - Moved the configuration descriptors inside the device descriptor so you can retrieve them without doing IO, e.g: deviceConfigs :: DeviceDesc -> [ConfigDesc] - Implemented standard device requests that are missing from libusb. - Made the timeout of I/O operations explicit. Now all I/O operations return an additional Bool that indicates if the operation has timed out. If an operation timed out does not mean there is no result, it just means that the result may be incomplete. - Added experimental (and still untested) support for iteratees for doing predictable, high-performance, safe, and elegant input processing using the iteratee package. See module: System.USB.IO.Synchronous.Enumerator - Fixed some asynchronous exception related bugs (put a needed bracket, block and unblock here and there). - Finally some functions, constructors and types got renamed, documentation got updated and extended and some refactoring has taken place. As always: questions, comments and patches are more than welcome. darcs get http://code.haskell.org/~basvandijk/code/usb regards, Bas

On Wed, Dec 9, 2009 at 4:20 PM, stefan kersten
looks great, thanks! do you happen to have some example code for working with HID devices (mice, keyboards, etc.)?
The usb package does not support the various device classes directly. You won't find a function like "isKeyPressed ∷ Device → KeyCode → IO Bool". But you could write it based solely on functions from the usb package. Enumerate the devices connected to your system, find your HID device, open a handle (or enter a safe region), choose an interface and an alternative and finally send some sort of control request encoded in a ByteString. The actual bytes you need to send in order to discover if some key on your USB keyboard is pressed is defined somewhere in the USB HID device class specification. If you really need that kind of functionality then you could create a package "usb-hid" that offers an abstraction over the HID device class. But if you just want to know if some key is pressed then a much simpler solution would be to use a library like SDL or GLUT. Keep in mind that all functions in the usb package run in *client side*. To actually use a device (communication) you need the proper permissions, which in practice implies super-user privileges. Libraries like SDL interface with the kernel drivers and do not need such permissions (correct me if I'm wrong). Regards, Roel

hi roel, On 09.12.09 16:50, Roel van Dijk wrote:
On Wed, Dec 9, 2009 at 4:20 PM, stefan kersten
wrote: looks great, thanks! do you happen to have some example code for working with HID devices (mice, keyboards, etc.)?
The usb package does not support the various device classes directly. You won't find a function like "isKeyPressed ∷ Device → KeyCode → IO Bool". But you could write it based solely on functions from the usb package. Enumerate the devices connected to your system, find your HID device, open a handle (or enter a safe region), choose an interface and an alternative and finally send some sort of control request encoded in a ByteString. The actual bytes you need to send in order to discover if some key on your USB keyboard is pressed is defined somewhere in the USB HID device class specification.
ok, thanks. i just thought you might have something ready to use ;)
If you really need that kind of functionality then you could create a package "usb-hid" that offers an abstraction over the HID device class. But if you just want to know if some key is pressed then a much simpler solution would be to use a library like SDL or GLUT.
i'm interested in "headless" appliances, where no window system is actually running. on linux i could use the input device layer, but it would be nice to have something more portable ... <sk>
participants (3)
-
Bas van Dijk
-
Roel van Dijk
-
stefan kersten