would manufacturer-supplied linux driver source code suffice? i can't
buy you one, but i can send you the linux driver sources.
Adrian Chadd wrote:
On 11 June 2011 03:48, Jim Bryant wrote:
this is with if_urtw.c patched to change L to B as you supplied.
I'm here for testing..
ng Kong is selling these for under $20 USD.
Bernhard Schmidt wrote:
On Thursday, June 09, 2011 22:34:18 Jim Bryant wrote:
I just bought one of those chinese (apparently the same unit relabeled
and being sold by multiple companies) realtek RTL8187B wifi units. The
price is right.
The lab
I just bought one of those chinese (apparently the same unit relabeled
and being sold by multiple companies) realtek RTL8187B wifi units. The
price is right.
The label name on this one is WiFySky 1500mW.
other than the fact that the case it is enclosed in is really cheesy,
there is a more im
excuse me while i pull my head out of my posterior...
yup.
it wasn't DRIVER_MODULE() doing it... it was the usb_fifo_attach
i think i'm back on the right track now... thanks for pointing me in
the right direction.
Hans Petter Selasky wrote:
Hi,
On Wednesday 25 May 2011 21
g make_dev/cdevsw?
i would prefer to not have DRIVER_MODULE create the device nodes.
am i missing something? i again apologize for the newbie questions...
jim
Hans Petter Selasky wrote:
On Tuesday 24 May 2011 23:19:27 Jim Bryant wrote:
if i add such an interface to the current DRIVER_MODU
i'm in the process of both learning the driver interface and writing a
usb driver for a multimedia product.
i'm kind of stuck here, as i'm seeing two distinct, and possibly
mutually exclusive interfaces here.
the test framework i'm currently using is the DRIVER_MODULE macro, but
it lacks the
thank you.
i forgot to add.. ultimately, this was intended for -STABLE
Hans Petter Selasky wrote:
On Thursday 12 May 2011 22:15:47 Jim Bryant wrote:
thanks, I shall take a look at youtube when I can.
The context diff patch is attached, cwd for the patch should be /usr/src.
http
D 0x0044 Antec Veris Elite VFD Panel, Knob, and
Remote
+ product SOUNDGRAPH SSTONE_LC160xffdc Silverstone LC16 VFD Panel,
Knob, and Remote
+
/* Speed Dragon Multimedia products */
product SPEEDDRAGON MS3303H0x110b MS3303H Serial
Jim Bryant wrote:
thanks, I shall take
thanks, I shall take a look at youtube when I can.
The context diff patch is attached, cwd for the patch should be /usr/src.
Hans Petter Selasky wrote:
On Wednesday 11 May 2011 22:57:32 Jim Bryant wrote:
Can someone please add the following entries to usbdevs?
vendor SOUNDGRAPH
Can someone please add the following entries to usbdevs?
vendor SOUNDGRAPH0x15C2 Soundgraph, Inc.
product SOUNDGRAPH IMON_VFD 0x0044 Antec Veris
Elite VFD Panel and Remote
product SOUNDGRAPH SILVERSTONE_LC16 0xFFDC Silverstone LC16 VFD
Panel and Remote
A
ah, i'm under -stable.
Alexander Leidinger wrote:
Quoting Jim Bryant (from Mon, 30 Aug 2010
19:22:49 -0500):
easy fix. just drop the _np
the functions are there under legacy naming.
Not in my revision of FreeBSD-current. I commented it out like HPS
suggested (the right way, wit
easy fix. just drop the _np
the functions are there under legacy naming.
Alexander Leidinger wrote:
Hi,
I try to port a linux userland USB program and I get the following
error message when trying to link to libusb (current as of r210105):
---snip---
cc -lusb -lm -o fowsr fowsr.o
fowsr.o(.
.byte 0x4
.long .LCFI0-.LFB3
.byte 0xe
.uleb128 0x10
.align 8
.LEFDE1:
.ident "GCC: (GNU) 4.2.1 20070719 [FreeBSD]"
9:22:00pm orb(16):
Jim Bryant wrote:
well, i can't speak for K&R 1978, as i can't currently find my copy,
n Appendix A.
Exercise 4-14. Define a macro swap(t,x,y) that interchanges two
arguments of type t.
(Block structure will help.)
Jim Bryant wrote:
u.. you were saying???
8:58:44pm orb(19): cat bs3.c
#include
int main(void)
{
int toshiftornottoshift = 0x8000;
printf("%d\n", toshift
:
.LSFDE1:
.long .LEFDE1-.LASFDE1
.LASFDE1:
.long .LASFDE1-.Lframe1
.long .LFB3
.long .LFE3-.LFB3
.uleb128 0x0
.byte 0x4
.long .LCFI0-.LFB3
.byte 0xe
.uleb128 0x10
.align 8
.LEFDE1:
.ident "GCC: (GNU) 4.2.1
ZE 0x8000 /* bytes */
#define ULPT_IFQ_MAXLEN 2 /* units */
#define UR_GET_DEVICE_ID0x00
Hans Petter Selasky wrote:
On Friday 27 August 2010 10:53:38 Jim Bryant wrote:
it'll be a pair of character devices.
lirc compat is a goal
vices in this, and due to the multiple
functions, the write() interface will be via variable length typed
packets (type, length, data), the read() interface envisioned will be
similar if i implement buffering of knob input, or single bytes
otherwise, one for each of the three active states.
driver.
Hans Petter Selasky wrote:
On Thursday 26 August 2010 23:29:35 Jim Bryant wrote:
Actually, all of my test programs (for testing my reverse engineering
efforts) have been done in libusb-1.0.
I would actually like to write kernel-level drivers though for these.
Then you s
09:17:24 Jim Bryant wrote:
unsigned char
Try to use the:
uint8_t
uint16_t
uint32_t
int8_t
int16_t
int32_t
types when describing data types. Also think about endianness and that 32-bit
reads/writes must be 32-bit aligned. Else use UGETDW() and similar functions.
yes, i will use mutexes in the kernel code. what i pasted was one
function from a userland libusb-1 test program.
the imonSendCommand(); function encapsulates the control request.
Hans Petter Selasky wrote:
On Friday 27 August 2010 09:17:24 Jim Bryant wrote:
is this level of bit-fiddling
ok, here's a dilemma...
the imon vfd has a bargraph mode (called equalizer mode using the
soundgraph imon software in winblowz) has a certain level of wierdness
in it.
i am leaning towards inclucing it's data massaging into the kernel
driver, as it's use is a bit touchy.
it has off and six
ther wm) please check under x for
reverse behavior.
Alexander Best wrote:
On Thu Aug 26 10, Jim Bryant wrote:
when you had to press it twice, was that only for the first attempt, and
did pressing it once after that turn it off? and once after that, on?
exactly. it might be a bit easier t
i was under the impression that it is userland-only.
Jim Bryant wrote:
does the libusb interface apply to kernel-level drivers, or is it
userland?
Hans Petter Selasky wrote:
On Thursday 26 August 2010 22:32:44 Hans Petter Selasky wrote:
where can i find documentation on this subsystem
does the libusb interface apply to kernel-level drivers, or is it userland?
Hans Petter Selasky wrote:
On Thursday 26 August 2010 22:32:44 Hans Petter Selasky wrote:
where can i find documentation on this subsystem?
man libusb
--HPS
Actually, all of my test programs (for testing my reverse engineering
efforts) have been done in libusb-1.0.
I would actually like to write kernel-level drivers though for these.
Hans Petter Selasky wrote:
On Thursday 26 August 2010 19:59:18 Jim Bryant wrote:
i have some usb devices, in
tree would benefit from having both drivers once
completed.
Jim Bryant wrote:
i have some usb devices, in the hid class, that i am wanting to write
some drivers for.
seeing that one of these previously had an older non-submitted driver
for 5.x-7.x online, i thought that might be a good starting
i have some usb devices, in the hid class, that i am wanting to write
some drivers for.
seeing that one of these previously had an older non-submitted driver
for 5.x-7.x online, i thought that might be a good starting point (the
imon vfd/lirc driver), but that does not work, due to the changes
when you had to press it twice, was that only for the first attempt, and
did pressing it once after that turn it off? and once after that, on?
i just read your note here, and the following one about the long delays
(kern/99538), and was able to duplicate the two-press thing.
amd64 here, unde
28 matches
Mail list logo
