Re: usb/155663: [usbdevs] [patch] Add support for Supertop Nano 1GB USB stick
Synopsis: [usbdevs] [patch] Add support for Supertop Nano 1GB USB stick State-Changed-From-To: open-closed State-Changed-By: brueffer State-Changed-When: Sat Feb 15 14:24:56 CET 2014 State-Changed-Why: Support for this was added in r241553 some time ago. Thanks for the contribution! http://www.freebsd.org/cgi/query-pr.cgi?pr=155663 ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/182936: [patch] [usbdevs] if_run update for Beklin F6D4050v2
Synopsis: [patch] [usbdevs] if_run update for Beklin F6D4050v2 State-Changed-From-To: open-closed State-Changed-By: brueffer State-Changed-When: Fri Feb 7 20:45:31 CET 2014 State-Changed-Why: This patch was applied in r256500 and merged back to the 10 and 9 branches. Thanks for the submission! http://www.freebsd.org/cgi/query-pr.cgi?pr=182936 ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/178773: [usbdevs] [patch] Huawei E303 USB 3G modem support
Synopsis: [usbdevs] [patch] Huawei E303 USB 3G modem support State-Changed-From-To: open-feedback State-Changed-By: brueffer State-Changed-When: Wed Feb 5 15:01:03 CET 2014 State-Changed-Why: These product IDs were added as Huawei E3131 in r238493, can you confirm this works with your device? They are both in 10-STABLES and 9-STABLE. Sorry for the delay in processing this PR! Responsible-Changed-From-To: freebsd-usb-brueffer Responsible-Changed-By: brueffer Responsible-Changed-When: Wed Feb 5 15:01:03 CET 2014 Responsible-Changed-Why: These product IDs were added as Huawei E3131 in r238493, can you confirm this works with your device? They are both in 10-STABLES and 9-STABLE. Sorry for the delay in processing this PR! http://www.freebsd.org/cgi/query-pr.cgi?pr=178773 ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: final usb question
Am Sonntag, 8. Juni 2008 16:35:08 schrieb Chuck Robey: This replaces my last usb question, because (even though I think the answer to that one confirms the utter insanity of the people who wrote the USB-HID spec), I have absolute confirmation of the fact that I cannot, in situations where the report descriptor has multiple sections ID'd by multiple report IDs, force the USB peripheral to send me the report ID that makes the best sense, and I must be satisfied with whatever the device sends me. That's ridiculous, but I wrote down the reference, just so I could look back at it and confirm to myself that I wasn't dreaming any of this. As a better illustration of that, my tablet has report IDs 7, 8, and 9. ID# 7 is the only one that matches well, but the device manufacturer has set it up to respond ONLY with report ID# 9. If I _could_ change that, I surely would, and I spent a LOT of time investigating until I absolutely found hard confirmation of the fact that I can't. If you get lucky and have a mfr sending all of the report ID's, you then can toss out the ones you don't like, but if they only send one (as in my case), well, you're screwed. What a stupid spec! Just because you don't understand the reasoning behind this part of the spec, it doesn't make it ridiculous automatically, so please stop bashing the spec as it doesn't help in any way. In your case the report IDs directly correspond to 3 different top level application collections: ID 7: Digitizer Pen ID 8: Mouse (relative coordinates) ID 9: Mouse (absolute coordinates) This way, each application collection can be handled by a generic driver instead of requireing a special driver for the whole device or interface. This isn't supported by our HID code, yet, but it will be (I'm working on that part). If your tablet only uses report ID 9 regardless of what device (pen or mouse) you use on it, this is certainly the vendor's fault but not the fault of the HID spec. My question now regards parsing of the input data using FreeBSD-supplied functions (which seems to me to mean things in libusbhid). Even though I can get hid_get_item and then hid_locate() to work for me, it's only by ignoring incorrect return values. Past that, the final point would be to use hid_get_data() to select and scale the data (which I gather through a read() of a scanned-for device such as uhid0) EXCEPT that I cannot get anything but a integer zero to return to me. As I told you before in private mail, see the source of usbhidctl(1) for examples on how to use libusbhid functions. hid_get_data() is being used there as well. Darn hid_get_data() just doesn't work. I'm probably missing some code assumption that didn't get illustrated in the man page. The only example I can get for it (the kernel code) is in dev/usb/ums.c, using the code in sys/dev/usb/hid.c, BUT the proto for this kernel code just looks _really_ different than the proto for the libusbhid functions. Headers and declarations are set up to make it really evil to try to use the kernel code in the user-mode code. I'm possibly going to have to adapt the kernel code to see if it can be forced to run in usermode. The kernel has its own HID functions which are mostly, but not entirely, the same than the counterparts in libusbhid. Does the libusbhid stuff work? Is there any sort of example, anywhere? Or, should I copy and adapt the kernel code? I could do the 3rd item, but it also seems like a really bad way to go. What's the right path here? Am I being stupid in missing the obvious? There's even one other question ... I'd heard some while back that someone else was preparing a separate implementation of the hid code. Do you know of anything like that, anything I could maybe replace the libusbhid code with? That would be me. Markus signature.asc Description: This is a digitally signed message part.
Re: dumping usb device reports
Am Donnerstag, 20. März 2008 23:47:25 schrieb Chuck Robey: I need to take a look at what crud comes in from my tablet, because I need to test my understanding of it's configuration descriptors. Ultimately, I need to be able to view the raw data in hex. I'm NOT talking about the stuff that krepdump puts out (thje configuration descriptors) I'm talking about the reports. Anyone know how I might do this? Understand, the device I'm talking about has no FreeBSD device, so it won't just have a device file in /dev/ I could dump from. Let uhid(4) attach to the device (remove ums(4) from your kernel config if neccessary or unload the ums(4) module), then: # cat /dev/uhid0 | hd Markus signature.asc Description: This is a digitally signed message part.
Re: getting my new graphic tablet cooperating with gimp
Am Donnerstag, 14. Februar 2008 20:23:32 schrieb Chuck Robey: Markus Brueffer wrote: I appreciate the extra information. In fact, I am having one heck of a time trying to figure out exactly how to parse this. I am reading with the HID1_11 spec on my knee at all times, but I swear, I have never seen such a poorly written document! It's not _that_ bad, but it surely lacks several clarifications in some areas and some information on specific topics is scattered across the whole document. Maybe I'm not used to the style, but reading this reminds me of the first few times I plowed my way thru the sgml spec, before I finally realized those guys weren't trying to get anything done, they were trying only to lay a foundation for a foundation for a way to get things done. Getting past that was difficult, and I find specific sections of the usbhid spec just as difficult. There is little or no linkage between the sections that describe features, and the sections that demonstrate how to use those features. As one example (which I think I've finally figured out), section 4.2 (Subclass), the subparagraph below that titled Subclass Codes uses the term (in italics) of bInterfaceSubClass. It describes one usagfe where it would be zero (0), but doesn't bother to say what the other use would be, nor give any example of what context you'd want to use this statement. There are currently only 2 types of subclasses for HID devices: no subclass (0) and boot interface subclass (1). Mice or keyboards e.g. can choose to implement 2 modes: boot mode and report mode. In boot mode, the data that the mouse returns is layed out in a specific way (described in appendix B), which is always the same, so there is no need to implement a full fledged HID report descriptor parser. This is especially usefull in very early boot stages like for the BIOS. When the system loads the operating system, the mouse gets switched into report mode and all features are available from that point. For the meaning of an Interface you should have a look at the USB spec itself, expecially how usb devices are made up w.r.t. the different descriptors and what they mean. I've written specs myself, but never one that did such a great job of obfuscation. I doubt, strongly, that any of you could do as badly (unless you were going thru perhaps 3 levels of language translation, that would do it). Anyhow, that's the reason why I am not yet finished in figuring out the parsing of my own unit's config dump. Best thing to get started is IMHO to get an idea about what reports are and to get the raw report descriptor of a simple device (e.g. a mouse if it's not from a keyboard/mouse combo) and start decoding it by hand. The sources of the libusbhid parser might be of help as well, although it contains several bugs and isn't spec compliant in several cases, but it might get you an idea of what's going on. Furthermore playing with usbhidctl might be of help. I have written a completly new fully spec compliant HID parser which is soon ready for public consumption as part of a new libhid. It contains many comments and should be easy to understand. The data representation directly takes the tree-like structure of a decoded report descriptor into account so that it's easy to write drivers that only handle one or more specific application collections. Furthermore physical descriptors are supported and the data handling functions hide the concept of report IDs so that it's less error prone to develop HID drivers (ums(4) e.g. doesn't support reports other than report 0 which is the reason that many of todays mice don't work). The parser itself will hopefully replace our current in-kernel HID parser. OK, couple more questions: would the state of your new libhid be far enough along that it might be possible for me to study it? If it were, could I get a copy, if I agreed that you are giving me the copy for study only, that I'm not to release it anywhere myself? Nope, not yet, as there are some parts still in flux. Additionally some documentation is still missing, especially documentation for the tree itself, that is being built by the parser. I'll send you a copy as soon as it's ready. Another thing, is there any way, beyond my forcing the action in patched code, to get the uhid driver to claim my device? I mean, some system configuration method to force this, like it used to be possible back a long time ago in the old usbd.conf? I might be able to figure some things out, if I could experiment with usbhidctl, if I could use it thru uhid. Not that I know of. But getting uhid(4) to recognize the device is actually quite easy. Please send me the output of udesc_dump (sysutils/udesc_dump in ports) for that device and I'll send you a patch. I am having a terrible time trying to figure out the actual scope of each statement, which refers to what. I don't run any piece
Re: getting my new graphic tablet cooperating with gimp
Am Mittwoch, 13. Februar 2008 18:28:09 schrieb Chuck Robey: Torfinn Ingolfsen wrote: On Sun, 10 Feb 2008 18:10:52 +0100 Kai Wang [EMAIL PROTECTED] wrote: On Sat, Feb 09, 2008 at 05:27:55PM -0500, Chuck Robey wrote: I have a nice new UC-Logic WP8060-TAB08, sometimes called the Superpen, and I want to get it working so's I can make fine art with it (yeah, I'm a dreamer, so what else is new, hey?) The return off of dmesg is: ums0: UC-LOGIC Tablet WP8060U, class 0/0, rev 1.10/0.00, addr 2 on uhub0 ums0: X report 0x0002 not supported device_attach: ums0 attach returned 6 This is because your tablet use absolute coordinates (most tablets do) while ums(4) currently only support relative ones. Could you please try to dump your pen's report descriptor and paste it here, thus we can have more infomation? I appreciate the extra information. In fact, I am having one heck of a time trying to figure out exactly how to parse this. I am reading with the HID1_11 spec on my knee at all times, but I swear, I have never seen such a poorly written document! It's not _that_ bad, but it surely lacks several clarifications in some areas and some information on specific topics is scattered across the whole document. Best thing to get started is IMHO to get an idea about what reports are and to get the raw report descriptor of a simple device (e.g. a mouse if it's not from a keyboard/mouse combo) and start decoding it by hand. The sources of the libusbhid parser might be of help as well, although it contains several bugs and isn't spec compliant in several cases, but it might get you an idea of what's going on. Furthermore playing with usbhidctl might be of help. I have written a completly new fully spec compliant HID parser which is soon ready for public consumption as part of a new libhid. It contains many comments and should be easy to understand. The data representation directly takes the tree-like structure of a decoded report descriptor into account so that it's easy to write drivers that only handle one or more specific application collections. Furthermore physical descriptors are supported and the data handling functions hide the concept of report IDs so that it's less error prone to develop HID drivers (ums(4) e.g. doesn't support reports other than report 0 which is the reason that many of todays mice don't work). The parser itself will hopefully replace our current in-kernel HID parser. I am having a terrible time trying to figure out the actual scope of each statement, which refers to what. I don't run any piece of Windows stuff here, so many of the pieces of demo software I have found on the web do me no good. I didn't find any windows software that really made it easier to understand the spec. It's IMHO easier to directly get your hands dirty and to read the code of an HID parser. I'm not giving up, I keep on making new discoveries, but if anyone knows of a description of HID that involves some real use of English, I sure would appreciate a pointer to it. If you have any specific questions, please drop me a mail. Markus signature.asc Description: This is a digitally signed message part.
Re: usb/119411: Co-ordinate system of mouse
Am Montag, 7. Januar 2008 09:22:27 schrieb Sujai Edwin Moses: I am getting negative values of y-axis when i move the mouse upwards. Is this a problem with the mouse or normal? if normal, can you tell me the co-ordinate system used by the mouse? This is perfectly normal. For details about the coordinate system please see chapter 5.9 of the HID spec. You can find it here: http://www.usb.org/developers/hidpage/ Markus signature.asc Description: This is a digitally signed message part.
Re: usb/119411: Co-ordinate system of mouse
The following reply was made to PR usb/119411; it has been noted by GNATS. From: Markus Brueffer [EMAIL PROTECTED] To: freebsd-usb@freebsd.org Cc: Sujai Edwin Moses [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: usb/119411: Co-ordinate system of mouse Date: Mon, 7 Jan 2008 23:40:47 +0100 --nextPart37532608.HuiN2vj0Ze Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Montag, 7. Januar 2008 09:22:27 schrieb Sujai Edwin Moses: I am getting negative values of y-axis when i move the mouse upwards. Is this a problem with the mouse or normal? if normal, can you tell me the co-ordinate system used by the mouse? This is perfectly normal. For details about the coordinate system please se= e=20 chapter 5.9 of the HID spec. You can find it here: http://www.usb.org/developers/hidpage/ Markus --nextPart37532608.HuiN2vj0Ze Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHgqp21I0Qcnj4qNQRAuyCAJ484OXcNghWCQDRS7hazvIiGt2qzACfSIeq fSTbeb6HKeoBU3717Y2vwgI= =z3UE -END PGP SIGNATURE- --nextPart37532608.HuiN2vj0Ze-- ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/110349: Support for USB mouses with W axis and inverted Z axis
Synopsis: Support for USB mouses with W axis and inverted Z axis State-Changed-From-To: open-closed State-Changed-By: markus State-Changed-When: Fri Mar 16 13:58:08 UTC 2007 State-Changed-Why: Duplicate of usb/110357 http://www.freebsd.org/cgi/query-pr.cgi?pr=110349 ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/110357: Support for USB mouses with W axis and inverted Z axis
Synopsis: Support for USB mouses with W axis and inverted Z axis Responsible-Changed-From-To: freebsd-usb-markus Responsible-Changed-By: markus Responsible-Changed-When: Fri Mar 16 13:59:07 UTC 2007 Responsible-Changed-Why: I'll handle this http://www.freebsd.org/cgi/query-pr.cgi?pr=110357 ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Wireless usb mouse
On Thursday 01 March 2007 18:51, Cesar Kuroiwa wrote: I recently got a microsoft wireless usb mouse/keyboard, but the mouse won't work under my freebsd 6-stable (the keyboard has no problem). Under linux everything works fine... I've looked everywhere on google but everything I got is that freebsd has some issues having two devices on the same usb port. Does this mean I'll never be able to use this mouse under freeBSD? Does anybody has a clue on how to make it work? While the latter is certainly true, it's most probably not the root of your problem. The problem with these mouse/keyboard combo devices is that FreeBSD's HID (Human Interface Device Standard) implementation is very limited and supports only the most basic devices. I'm currently working on restructuring and fixing our HID code (which includes the mouse driver), but as I'm short on time, progress is currently slow. You might however, if you are running 6.x, try the following kernel module: http://people.freebsd.org/~markus/stuff/ums.ko Build a kernel without device ums and load the above mentioned kernel module via kldload(8). Please report back, if it works for you or not. Markus -- Markus Brueffer | GPG-Key: http://people.FreeBSD.org/~markus/markus.asc [EMAIL PROTECTED] | FP: 3F9B EBE8 F290 E5CC 1447 8760 D48D 1072 78F8 A8D4 [EMAIL PROTECTED] | FreeBSD: The Power to Serve! pgpZ31t42YSiL.pgp Description: PGP signature
Re: usb/106565: [PATCH] ums(4) does not work if the mouse defaults to boot protocol
Synopsis: [PATCH] ums(4) does not work if the mouse defaults to boot protocol Responsible-Changed-From-To: freebsd-usb-markus Responsible-Changed-By: markus Responsible-Changed-When: Wed Dec 13 02:34:00 UTC 2006 Responsible-Changed-Why: Good catch, I'll handle it. http://www.freebsd.org/cgi/query-pr.cgi?pr=106565 ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/106435: Possible buffer overflow in dev/usb/ums.c
Synopsis: Possible buffer overflow in dev/usb/ums.c Responsible-Changed-From-To: freebsd-usb-markus Responsible-Changed-By: markus Responsible-Changed-When: Sat Dec 9 13:08:55 UTC 2006 Responsible-Changed-Why: I'll handle this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=106435 ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb descriptor bogus?
Do you still need help with the descriptor? Markus On Sunday 08 October 2006 23:24, Rene Ladan wrote: Hi, I came up with an output descriptor for the Xbox 360 controller, but the output from usbhidctl(1) is not completely as expected. The attached file rdesc.txt contains the actual results, with lines starting with # containing the expected results. The output was generated using usbhidctl(1) and libusbhid from OpenBSD with -rv as argument. I also attached the descriptor itself (in .h and .hid format), the .hid file was validated using Descriptor Tool 2.4. This is a small windows program obtainable from http://www.usb.org/developers/hidpage/dt2_4.zip Any ideas what is wrong with the descriptor (or maybe libusbhid) ? Regards, Rene -- Markus Brueffer | GPG-Key: http://people.FreeBSD.org/~markus/markus.asc [EMAIL PROTECTED] | FP: 3F9B EBE8 F290 E5CC 1447 8760 D48D 1072 78F8 A8D4 [EMAIL PROTECTED] | FreeBSD: The Power to Serve! pgps9s58b5fNS.pgp Description: PGP signature
Re: [Patch] Fix collection entry parsing in libusbhid
Am Thursday 16 February 2006 08:47 schrieb Alexander Leidinger: Markus Brueffer [EMAIL PROTECTED] wrote: Furthermore I have removed the loop in REPORT_SAVED_COLL. If someone knows why it was there in the first place, please share your wisdom :) This is done in many places in the source. It's a common way of writting a macro which is usable like a function (yes, this macro returns, so it doesn't _work_ like a function, but this is not the point). Usually this is used with macros which take arguments. You just can add a ';' after the use of the macro without having to remember if you need to do it, or if your compiler may moan because of an empty statement. Have a look into style(9), it also has to say something about it. Ah, I see. Thanks for the explanation. I have updated the diff to not remove the loop. Markus -- Markus Brueffer | GPG-Key: http://people.FreeBSD.org/~markus/markus.asc [EMAIL PROTECTED] | FP: 3F9B EBE8 F290 E5CC 1447 8760 D48D 1072 78F8 A8D4 [EMAIL PROTECTED] | FreeBSD: The Power to Serve! pgpV8YbFsO233.pgp Description: PGP signature
[Patch] Fix collection entry parsing in libusbhid
Hi, here is a patch for libusbhid which fixes parsing of collection entries if the collection has only non-variable Input/Output/Feature entries: http://people.freebsd.org/~markus/bt/parse.c.diff The problem ist that the output of collection pages has to be deferred until the report id is known. Without the patch, deferred collection pages are only reported correctly if variable Input/Output/Feature entries are present. The effect can be seen here (output of the hid descriptor dump of a Logitech MX5000 keyboard using bthidcontrol): http://people.freebsd.org/~markus/bt/mx5000_before.txt http://people.freebsd.org/~markus/bt/mx5000_after.txt Furthermore I have removed the loop in REPORT_SAVED_COLL. If someone knows why it was there in the first place, please share your wisdom :) Third change is the removal of REPORT_SAVED_COLL if the end of a collection is reached. All collection entries should have been reported by then. Ok to commit? Markus -- Markus Brueffer | GPG-Key: http://people.FreeBSD.org/~markus/markus.asc [EMAIL PROTECTED] | FP: 3F9B EBE8 F290 E5CC 1447 8760 D48D 1072 78F8 A8D4 [EMAIL PROTECTED] | FreeBSD: The Power to Serve! pgp9JuPinjTwf.pgp Description: PGP signature
