Re: [NEW] ugold(4) driver for Microdia's USB TEMPer variant (take 3)
On 05/09/13(Thu) 05:23, SASANO Takayoshi wrote: Hi all, Here is the driver for Microdia's USB TEMPer, take 3. http://www.uaa.org.uk/gomitext/2013/20130905/20130905.diff Thanks to mpi@ and testers of tech@. man is not yet, sorry. I'm ok with your diff, here's a man. I can commit it once your diff is in if it's ok. Index: Makefile === RCS file: /home/ncvs/src/share/man/man4/Makefile,v retrieving revision 1.555 diff -u -p -r1.555 Makefile --- Makefile4 Sep 2013 19:39:18 - 1.555 +++ Makefile5 Sep 2013 09:10:30 - @@ -57,7 +57,8 @@ MAN= aac.4 ac97.4 acphy.4 \ tlphy.4 thmc.4 tqphy.4 trm.4 trunk.4 tsl.4 tty.4 tun.4 twe.4 txp.4 \ txphy.4 uaudio.4 uark.4 uath.4 uberry.4 ubsa.4 ubsec.4 ubt.4 \ ucom.4 uchcom.4 ucycom.4 udav.4 udcf.4 udfu.4 udl.4 udp.4 udsbr.4 \ - uftdi.4 ugen.4 uguru.4 uhci.4 uhid.4 uhidev.4 uipaq.4 uk.4 ukbd.4 \ + uftdi.4 ugen.4 ugold.4 uguru.4 uhci.4 uhid.4 uhidev.4 uipaq.4 uk.4 \ + ukbd.4 \ ukphy.4 ulpt.4 umass.4 umbg.4 umct.4 umidi.4 umodem.4 ums.4 umsm.4 \ unix.4 uow.4 uoaklux.4 uoakrh.4 uoakv.4 \ upgt.4 upl.4 uplcom.4 ural.4 urio.4 url.4 urlphy.4 \ Index: ugold.4 === RCS file: ugold.4 diff -N ugold.4 --- /dev/null 1 Jan 1970 00:00:00 - +++ ugold.4 5 Sep 2013 09:10:30 - @@ -0,0 +1,46 @@ +.\$OpenBSD$ +.\ +.\ Copyright (c) 2009 Yojiro UO y...@nui.org +.\ +.\ Permission to use, copy, modify, and distribute this software for any +.\ purpose with or without fee is hereby granted, provided that the above +.\ copyright notice and this permission notice appear in all copies. +.\ +.\ THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES +.\ WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +.\ MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR +.\ ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +.\ WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +.\ ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF +.\ OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +.\ +.Dd $Mdocdate$ +.Dt UGOLD 4 +.Os +.Sh NAME +.Nm ugold +.Nd TEMPer Gold HID temperature sensor +.Sh SYNOPSIS +.Cd ugold* at uhidev? +.Sh DESCRIPTION +The +.Nm +driver provides support for pcsensors TEMPer gold devices. +The following devices are supported by the +.Nm +driver: +.Bl -column RDing TEMPer1V1.2 1 Temperature -offset indent +.It Em Device Ta Em Sensors +.It Li RDing TEMPer1V1.2 Ta 1 Temperature +.El +.Pp +The driver possesses a collection of sensor values which are +made available through the +.Xr sysctl 8 +interface. +.Sh SEE ALSO +.Xr intro 4 , +.Xr uhidev 4 , +.Xr uthum 4 , +.Xr sensorsd 8 , +.Xr sysctl 8
[NEW] ugold(4) driver for Microdia's USB TEMPer variant (take 3)
Hi all, Here is the driver for Microdia's USB TEMPer, take 3. http://www.uaa.org.uk/gomitext/2013/20130905/20130905.diff Thanks to mpi@ and testers of tech@. man is not yet, sorry. Regards, SASANO Takayoshi u...@mx5.nisiq.net
Re: [NEW] ugold(4) driver for Microdia's USB TEMPer variant (take 2)
Upgraded my icinga/cacti box to -current, latest ugold patch applied. All good: from dmesg OpenBSD 5.3-current (GENERIC.MP) #0: Wed May 29 09:47:39 CST 2013 r...@sbrnms..xxx:/usr/src/sys/arch/amd64/compile/GENERIC.MP uhidev0 at uhub3 port 1 configuration 1 interface 0 RDing TEMPerV1.2 rev 2.00/0.01 addr 2 uhidev0: iclass 3/1, 1 report id ugold0 at uhidev0 reportid 1 uhidev1 at uhub3 port 1 configuration 1 interface 1 RDing TEMPerV1.2 rev 2.00/0.01 addr 2 uhidev1: iclass 3/1 ugold1 at uhidev1 ugold1: type ds75/12bit (temperature) uhidev2 at uhub5 port 1 configuration 1 interface 0 RDing TEMPerV1.2 rev 2.00/0.01 addr 2 uhidev2: iclass 3/1, 1 report id ugold2 at uhidev2 reportid 1 uhidev3 at uhub5 port 1 configuration 1 interface 1 RDing TEMPerV1.2 rev 2.00/0.01 addr 2 uhidev3: iclass 3/1 ugold3 at uhidev3 ugold3: type ds75/12bit (temperature) sysctl hw.sensors.ugold* hw.sensors.ugold1.temp0=21.87 degC (inner) hw.sensors.ugold3.temp0=24.25 degC (inner) -luis On Sun, May 12, 2013 at 12:41 PM, SASANO Takayoshi u...@mx5.nisiq.netwrote: Hello, Here is the driver for Microdia's USB TEMPer with some fixes. http://www.uaa.org.uk/gomitext/2013/20130513/20130513.diff - removed intermediate buffer (sc_ibuf), all USB interrupt responses will be processed in ugold_intr(). - use uhidev_set_report() to issue HID command. - add ugold* at uhidev? into GENERIC for alpha, amd64, armish, hppa, i386, landisk, loongson, macppc, sgi (IP27, IP30, IP32), socppc and sparc64. Regards, SASANO Takayoshi u...@mx5.nisiq.net
Re: [NEW] ugold(4) driver for Microdia's USB TEMPer variant (take 2)
On 05/12/13 20:41, SASANO Takayoshi wrote: Hello, Here is the driver for Microdia's USB TEMPer with some fixes. http://www.uaa.org.uk/gomitext/2013/20130513/20130513.diff - removed intermediate buffer (sc_ibuf), all USB interrupt responses will be processed in ugold_intr(). - use uhidev_set_report() to issue HID command. - add ugold* at uhidev? into GENERIC for alpha, amd64, armish, hppa, i386, landisk, loongson, macppc, sgi (IP27, IP30, IP32), socppc and sparc64. Regards, SASANO Takayoshi u...@mx5.nisiq.net Hi, I have tried it on amd64 and it works fine : uhidev4 at uhub3 port 1 configuration 1 interface 0 RDing TEMPerV1.4 rev 2.00/0.01 addr 3 uhidev4: iclass 3/1, 1 report id ugold0 at uhidev4 reportid 1 uhidev5 at uhub3 port 1 configuration 1 interface 1 RDing TEMPerV1.4 rev 2.00/0.01 addr 3 uhidev5: iclass 3/1 ugold1 at uhidev5 ugold1: type ds75/12bit (temperature) # sysctl hw.sensors.ugold1 hw.sensors.ugold1.temp0=23.37 degC (inner) Cheers, benoit
[NEW] ugold(4) driver for Microdia's USB TEMPer variant (take 2)
Hello, Here is the driver for Microdia's USB TEMPer with some fixes. http://www.uaa.org.uk/gomitext/2013/20130513/20130513.diff - removed intermediate buffer (sc_ibuf), all USB interrupt responses will be processed in ugold_intr(). - use uhidev_set_report() to issue HID command. - add ugold* at uhidev? into GENERIC for alpha, amd64, armish, hppa, i386, landisk, loongson, macppc, sgi (IP27, IP30, IP32), socppc and sparc64. Regards, SASANO Takayoshi u...@mx5.nisiq.net
Re: [NEW] ugold(4) driver for Microdia's USB TEMPer variant
On 30/04/13(Tue) 17:39, Stuart Henderson wrote:
On 2013/04/30 15:06, Stuart Henderson wrote:
On 2013/03/31 17:56, SASANO Takayoshi wrote:
Hello,
I rewrote patched uthum(4) to new ugold(4) driver.
Thanks for advice by yuo@ and deraadt@.
Some comments inline.
Index: dev/usb/ugold.c
===
[...]
+/* Driver for Microdia's HID base TEMPer Temperature sensor */
+
+#include sys/param.h
+#include sys/proc.h
+#include sys/systm.h
+#include sys/kernel.h
+#include sys/malloc.h
+#include sys/device.h
+#include sys/conf.h
+#include sys/sensors.h
+
+#include dev/usb/usb.h
+#include dev/usb/usbhid.h
+#include dev/usb/usbdi.h
+#include dev/usb/usbdi_util.h
+#include dev/usb/usbdevs.h
+#include dev/usb/uhidev.h
+#include dev/usb/hid.h
Please make sure you include only the required headers, at least proc.h is
not needed.
+
+#ifdef USB_DEBUG
+#define UGOLD_DEBUG
+#endif
+
+#ifdef UGOLD_DEBUG
+int ugolddebug = 0;
+#define DPRINTFN(n, x) do { if (ugolddebug (n)) printf x; } while (0)
+#else
+#define DPRINTFN(n, x)
+#endif
+
+#define DPRINTF(x) DPRINTFN(0, x)
If you don't use the *N() variant, just keep it simple a only define the
DPRINTF() macro, this will also allow you to remove the ugolddebug
variable.
+
+/* Device types */
+#define UGOLD_TYPE_TEMPER0
+#define UGOLD_TYPE_UNKNOWN 0x
+
+/* sensors */
+#define UGOLD_TEMPER_INNER 0
+#define UGOLD_TEMPER_OUTER 1
+#define UGOLD_MAX_SENSORS2
+
+enum ugold_sensor_type {
+ UGOLD_SENSOR_UNKNOWN,
+ UGOLD_SENSOR_DS75,
+ UGOLD_SENSOR_MAXTYPES,
+};
+
+static const char * const ugold_sensor_type_s[UGOLD_SENSOR_MAXTYPES] = {
+ unknown,
+ ds75/12bit,
+};
+
+static uint8_t cmd_led_off[2] =
+ { 0x01, 0x00 };
+static uint8_t cmd_get_offset[8] =
+ { 0x01, 0x82, 0x77, 0x01, 0x00, 0x00, 0x00, 0x00 };
+static uint8_t cmd_init[8] =
+ { 0x01, 0x86, 0xff, 0x01, 0x00, 0x00, 0x00, 0x00 };
+static uint8_t cmd_get_data[8] =
+ { 0x01, 0x80, 0x33, 0x01, 0x00, 0x00, 0x00, 0x00 };
+
+struct ugold_sensor {
+ struct ksensor sensor;
+ int cal_offset; /* 10mC or m%RH */
+ int attached;
+ enum ugold_sensor_type dev_type;
+};
+
+struct ugold_softc {
+ struct uhidevsc_hdev;
+ usbd_device_handle sc_udev;
+ u_char sc_dying;
You don't use sc_dying so you can probably remove it and the *activate()
function also.
+ uint16_t sc_flag;
This field is also unused.
+ int sc_device_type;
Because you're attaching only one kind of device there's no need for
this field. I suggest you to remove it and all the unneeded logic that
comes with it.
+ int sc_initialized;
+ int sc_num_sensors;
+
+ /* uhidev parameters */
+ size_t sc_flen; /* feature report length */
+ size_t sc_ilen; /* input report length */
+ size_t sc_olen; /* output report length */
+
+ uint8_t *sc_ibuf;
+
+ /* sensor framework */
+ struct ugold_sensor sc_sensor[UGOLD_MAX_SENSORS];
+ struct ksensordevsc_sensordev;
+ struct sensor_task *sc_sensortask;
+};
+
+const struct usb_devno ugold_devs[] = {
+ { USB_VENDOR_MICRODIA, USB_PRODUCT_MICRODIA_TEMPER },
+};
+#define ugold_lookup(v, p) usb_lookup(ugold_devs, v, p)
+
+int ugold_match(struct device *, void *, void *);
+void ugold_attach(struct device *, struct device *, void *);
+int ugold_detach(struct device *, int);
+int ugold_activate(struct device *, int);
+
+int ugold_issue_cmd(struct ugold_softc *, uint8_t *, int, int);
+int ugold_read_data(struct ugold_softc *);
+int ugold_init_device(struct ugold_softc *);
+void ugold_setup_sensors(struct ugold_softc *);
+int ugold_setup_device(struct ugold_softc *);
+
+void ugold_intr(struct uhidev *, void *, u_int);
+void ugold_refresh(void *);
+void ugold_refresh_temper(struct ugold_softc *);
+
+int ugold_ds75_temp(uint8_t, uint8_t);
+void ugold_print_sensorinfo(struct ugold_softc *, int);
+
+struct cfdriver ugold_cd = {
+ NULL, ugold, DV_DULL
+};
+
+const struct cfattach ugold_ca = {
+ sizeof(struct ugold_softc),
+ ugold_match,
+ ugold_attach,
+ ugold_detach,
+ ugold_activate,
+};
+
+int
+ugold_match(struct device *parent, void *match, void *aux)
+{
+ struct usb_attach_arg *uaa = aux;
+ struct uhidev_attach_arg *uha = (struct uhidev_attach_arg *)uaa;
+
+ if (ugold_lookup(uha-uaa-vendor, uha-uaa-product) == NULL)
+ return UMATCH_NONE;
+
+ return (UMATCH_VENDOR_PRODUCT);
+}
+
+void
+ugold_attach(struct device *parent, struct device *self, void *aux)
+{
+ struct ugold_softc *sc = (struct ugold_softc *)self;
+ struct
Re: [NEW] ugold(4) driver for Microdia's USB TEMPer variant
Hello, sorry for late reply.
wow, there is many comments...
But anyway, I think that in your case you don't need it. Why don't you
update directly your sensor values when you receive the data in
ugold_intr() instead of copying to a intermediate buffer?
The device always works command (control pipe) - response (interrupt
pipe) cycle. I tried to replace uhidev_get_report() instead of reading
interrupt pipe, but it didn't work. (why?)
If only temperature data (as read temperature data command's response)
comes from interrupt pipe, I think it will be able to remove
intermediate buffer. But, other responses by initialize commands are
also using interrupt pipe. Is there any good idea to distinguish them?
+/*
+ * interrupt pipe is opened but data comes after ugold_attach()
+ * is finished. simply attach sensors here and the device will be
+ * initialized at ugold_refresh().
+ *
+ * at this point, the number of sensors is unknown. setup maximum
+ * sensors here and detach unused sensor later.
+ */
Why don't you initialize the device before opening the interrupt pipe?
ugold_init_device() gets the number of sensors and offset parameter,
they come from interrupt pipe. And I couldn't get any interrupt response
when issuing commands in ugold_attach().
After (exiting) ugold_attach(), I could get interrupt response.
+int
+ugold_issue_cmd(struct ugold_softc *sc, uint8_t *cmd, int len, int delay)
+{
+usb_device_request_t req;
+
+bzero(sc-sc_ibuf, sc-sc_ilen);
+
+req.bmRequestType = UT_WRITE_CLASS_INTERFACE;
+req.bRequest = UR_SET_REPORT;
+USETW(req.wValue, 0x0200);
+USETW(req.wIndex, 0x0001);
+USETW(req.wLength, len);
+if (usbd_do_request(sc-sc_udev, req, cmd))
+return EIO;
I would suggest you to have a look at uhidev_set_report{,_async}() instead of
writing your own version here.
I think this can replace with uhidev_set_report(), I will try rewrite.
+int
+ugold_init_device(struct ugold_softc *sc)
+{
+usb_device_request_t req;
+usbd_status error;
+
+/* send SetReport request to another (Keyboard) interface */
+req.bmRequestType = UT_WRITE_CLASS_INTERFACE;
+req.bRequest = UR_SET_REPORT;
+USETW(req.wValue, 0x0201);
+USETW(req.wIndex, 0x);
+USETW(req.wLength, sizeof(cmd_led_off));
+error = usbd_do_request(sc-sc_udev, req, cmd_led_off);
+if (error)
+return EIO;
Same here, this is likely to be another uhidev_set_report() with a
different interface, no?
Current ugold_attach() ignores keyboard interface, so sc_hdev in
ugold_softc points mouse inerface.
Maybe this SetReport will be able to replace issuing
uhidev_set_report() when detecting keyboard interface in
ugold_attach().
+/* init process */
+if (ugold_issue_cmd(sc, cmd_get_offset, sizeof(cmd_get_offset), 200))
+return EIO;
+
+/* received one interrupt message, it contains offset parameter */
+sc-sc_num_sensors = sc-sc_ibuf[1];
How can you be sure sc_ibuf contains the data you asked for?
Well, sanity check will be required.
Cheers,
--
SASANO Takayoshi u...@mx5.nisiq.net
Re: [NEW] ugold(4) driver for Microdia's USB TEMPer variant
On 2013/05/02 23:57, SASANO Takayoshi wrote:
+int
+ugold_issue_cmd(struct ugold_softc *sc, uint8_t *cmd, int len, int delay)
+{
+ usb_device_request_t req;
+
+ bzero(sc-sc_ibuf, sc-sc_ilen);
+
+ req.bmRequestType = UT_WRITE_CLASS_INTERFACE;
+ req.bRequest = UR_SET_REPORT;
+ USETW(req.wValue, 0x0200);
+ USETW(req.wIndex, 0x0001);
+ USETW(req.wLength, len);
+ if (usbd_do_request(sc-sc_udev, req, cmd))
+ return EIO;
I would suggest you to have a look at uhidev_set_report{,_async}() instead
of
writing your own version here.
I think this can replace with uhidev_set_report(), I will try rewrite.
*if* sc-sc_hdev.sc_report_id is set to 0 then I think this may be
something like: uhidev_set_report(sc-sc_hdev, 2, cmd, len)
the ugold(4) hardware I currently have access to is remote, so I can't
test this easily ;)
if sc_report_id isn't set how we need, then maybe we could at least
call usbd_set_report with hardcoded id.
Re: [NEW] ugold(4) driver for Microdia's USB TEMPer variant
On 2013/03/31 17:56, SASANO Takayoshi wrote: Hello, I rewrote patched uthum(4) to new ugold(4) driver. Thanks for advice by yuo@ and deraadt@. The diff for -current's /usr/src/sys is large to send mailing-list, so here is the URL: http://www2192ue.sakura.ne.jp/~uaa/gomitext/2013/20130331/20130331.diff If you want to try ugold(4) and already use Microdia's-variant-patched uthum(4) driver, revert original uthum(4). ok or comments, please. Cheers, -- SASANO Takayoshi u...@mx5.nisiq.net In the diff to usbdevs you have this: product MICRODIA_TEMPER 0x7401 TEMPer sensor it should be: product MICRODIA TEMPER 0x7401 TEMPer sensor Your diff as-is does build, but as soon as somebody runs make in /sys/dev/usb it will break. Generally, avoid editing usbdevs.h and usbdevs_data.h directly, just edit usbdevs and then run make to generate the other files. The driver also needs adding to GENERIC for the other USB-capable architectures. Works for me on i386 with $ dmesg|grep ugold ugold0 at uhidev0 reportid 1 ugold1 at uhidev1 ugold1: type ds75/12bit (temperature)
Re: [NEW] ugold(4) driver for Microdia's USB TEMPer variant
On 2013/04/30 15:06, Stuart Henderson wrote: On 2013/03/31 17:56, SASANO Takayoshi wrote: Hello, I rewrote patched uthum(4) to new ugold(4) driver. Thanks for advice by yuo@ and deraadt@. The diff for -current's /usr/src/sys is large to send mailing-list, so here is the URL: http://www2192ue.sakura.ne.jp/~uaa/gomitext/2013/20130331/20130331.diff If you want to try ugold(4) and already use Microdia's-variant-patched uthum(4) driver, revert original uthum(4). ok or comments, please. Cheers, -- SASANO Takayoshi u...@mx5.nisiq.net In the diff to usbdevs you have this: product MICRODIA_TEMPER 0x7401 TEMPer sensor it should be: product MICRODIA TEMPER 0x7401 TEMPer sensor Your diff as-is does build, but as soon as somebody runs make in /sys/dev/usb it will break. Generally, avoid editing usbdevs.h and usbdevs_data.h directly, just edit usbdevs and then run make to generate the other files. The driver also needs adding to GENERIC for the other USB-capable architectures. Works for me on i386 with $ dmesg|grep ugold ugold0 at uhidev0 reportid 1 ugold1 at uhidev1 ugold1: type ds75/12bit (temperature) ... Seems to work well enough; and unlike my uthum (one of the dual-sensor ones) it seems to stay attached without dropping out all the time. These are slightly slow adapting to temperature changes (presumably due to the metal case) for example this graph from moving the sensor from the front of a server room to the back (through hot/cold air containment curtains) http://junkpile.org/ugold.png shows it took about 10 minutes to stabilise again, but that's good enough for my needs :)
Re: [NEW] ugold(4) driver for Microdia's USB TEMPer variant
Sasano, your patch applies without problems in -current. This is what I see: uname -a: $ uname -a OpenBSD obsdbox.ticoit.net 5.3 GENERIC.MP#15 amd64 from dmesg: OpenBSD 5.3-current (GENERIC.MP) #15: Mon Apr 1 13:44:48 CST 2013 . . . uhidev3 at uhub4 port 2 configuration 1 interface 0 RDing TEMPerV1.2 rev 2.00/0.01 addr 3 uhidev3: iclass 3/1, 1 report id ugold0 at uhidev3 reportid 1 uhidev4 at uhub4 port 2 configuration 1 interface 1 RDing TEMPerV1.2 rev 2.00/0.01 addr 3 uhidev4: iclass 3/1 ugold1 at uhidev4 ugold1: type ds75/12bit (temperature) uhidev5 at uhub3 port 1 configuration 1 interface 0 RDing TEMPerV1.2 rev 2.00/0.01 addr 3 uhidev5: iclass 3/1, 1 report id ugold2 at uhidev5 reportid 1 uhidev6 at uhub3 port 1 configuration 1 interface 1 RDing TEMPerV1.2 rev 2.00/0.01 addr 3 uhidev6: iclass 3/1 ugold3 at uhidev6 ugold3: type ds75/12bit (temperature) sysctl hw.sensors: hw.sensors.ugold1.temp0=30.50 degC (inner) hw.sensors.ugold3.temp0=33.75 degC (inner) usbdevs -vd: Controller /dev/usb3: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x8086), rev 1.00 uhub3 port 1 addr 3: low speed, power 100 mA, config 1, TEMPerV1.2(0x7401), RDing(0x0c45), rev 0.01 uhidev5 uhidev6 port 2 addr 2: low speed, power 98 mA, config 1, USB Optical Mouse(0xc054), Logitech(0x046d), rev 54.00 uhidev0 Controller /dev/usb4: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x8086), rev 1.00 uhub4 port 1 addr 2: low speed, power 100 mA, config 1, HP USB Multimedia Keyboard(0x0841), CHICONY(0x04f2), rev 1.00 uhidev1 uhidev2 port 2 addr 3: low speed, power 100 mA, config 1, TEMPerV1.2(0x7401), RDing(0x0c45), rev 0.01 uhidev3 uhidev4 So far so good. Icinga is happy. -luis On Sun, Mar 31, 2013 at 2:56 AM, SASANO Takayoshi u...@mx5.nisiq.net wrote: Hello, I rewrote patched uthum(4) to new ugold(4) driver. Thanks for advice by yuo@ and deraadt@. The diff for -current's /usr/src/sys is large to send mailing-list, so here is the URL: http://www2192ue.sakura.ne.jp/~uaa/gomitext/2013/20130331/20130331.diff If you want to try ugold(4) and already use Microdia's-variant-patched uthum(4) driver, revert original uthum(4). ok or comments, please. Cheers, -- SASANO Takayoshi u...@mx5.nisiq.net
[NEW] ugold(4) driver for Microdia's USB TEMPer variant
Hello, I rewrote patched uthum(4) to new ugold(4) driver. Thanks for advice by yuo@ and deraadt@. The diff for -current's /usr/src/sys is large to send mailing-list, so here is the URL: http://www2192ue.sakura.ne.jp/~uaa/gomitext/2013/20130331/20130331.diff If you want to try ugold(4) and already use Microdia's-variant-patched uthum(4) driver, revert original uthum(4). ok or comments, please. Cheers, -- SASANO Takayoshi u...@mx5.nisiq.net
