thanks. am doing that now.
I already have one patch for this one
what kind of idiot defines a constant assignment for a 32k buffer as a
15 bit left shift of 1?
clever, yes. but in production, stupid.
a constant should be just that, a constant, and thus require no
computation at runtim
Hi
I've got a 3g usb stick that works fine with 8.0-STABLE from Jan 3rd
2010, but does not with 8.1-RELEASE. Its a Vodafone branded stick
bought in New Zealand.
With FreeBSD 8.0 it prints this when I insert the stick:
usb_test_autoinstall: Eject CD command status: USB_ERR_PENDING_REQUESTS
u
On Fri Aug 27 10, Alexander Best wrote:
> On Thu Aug 26 10, Jim Bryant wrote:
> > oh freaking wow!!!
> >
> > this just got weirder!!!
>
> just found PR 139144. maybe that's the cause for the problem? are you loading
> a
> a specific keymap?
>
> i'm using german.iso
>
> cheers.
> alex
>
> >
>
On Thu Aug 26 10, Jim Bryant wrote:
> oh freaking wow!!!
>
> this just got weirder!!!
just found PR 139144. maybe that's the cause for the problem? are you loading a
a specific keymap?
i'm using german.iso
cheers.
alex
>
> i haven't had the two-press thing again, but since you listed the stat
On Thu Aug 26 10, Jim Bryant wrote:
> oh freaking wow!!!
>
> this just got weirder!!!
>
> i haven't had the two-press thing again, but since you listed the status
> of the keys themselves, i decided to check just now...
>
> numlock off = numbers
> numlock on = cursor pad
nope. not the case her
since the display is 16x2, i kind of think a tty device would be gumming
up the works. no sense in cooking the output.
scrolling is done manually. the entire display of both lines has to be
sent in every write. the samsung vfd panel itself has far more features
than soundgraph (the manufact
On Friday 27 August 2010 10:53:38 Jim Bryant wrote:
> it'll be a pair of character devices.
>
> lirc compat is a goal of this project though. most of the work is done
> on that front, i just need to port that over from linux. the features
> of the imon remote control are well-supported in lirc
it'll be a pair of character devices.
the imon vfd is oem'ed to virtually EVERY high-end vfd-equipped htpc
case on the market, all such tend to have the remote control interface
as well built into the unit. the difference exists with the
knob/button, some have it, others don't. the knob/butt
will do, thanks.
as far as alignment, i'll try to align on 64 for more efficient intel/amd.
and there shall be no holy wars, all values are broken down to bytes or
nybbles, peace shall prevail. buffer lengths are fixed at 8 bytes.
Hans Petter Selasky wrote:
On Friday 27 August 2010 09:17:24
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
On Friday 27 August 2010 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.
--H
On Friday 27 August 2010 09:17:24 Jim Bryant wrote:
> is this level of bit-fiddling acceptable in the kernel?
Yes, this is Ok.
One more thing: Add a mutex pointer argument to functions that can sleep.
Is the code you showed doing control requests?
--HPS
_
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
On Thursday 26 August 2010 23:50:28 Alexander Best wrote:
> hi there,
>
> when i connect my mobile phone to a recent HEAD (amd64; r211393) i get the
> following:
>
> ugen3.3: at usbus3
> umass0: on usbus3
> (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
> (probe0:umass-sim0:0:0:0)
On Thursday 26 August 2010 23:42:46 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?
> >
> > man
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 should look at existing drivers in /sys/dev/
16 matches
Mail list logo
