On Sat, Mar 03, 2007 at 10:41:19AM +0100, Gard Spreemann wrote:
> Hi. I don't know if this is the correct list to hit, so please excuse me if
> it's not.
>
> I have a DLP-TILT with an FT232RL with PID 0xfbfa which I couldn't get
> working
> with the ftdi_sio drivers. I emailed FTDI, and they s
Alan Stern ha scritto:
>
> It should work even better than posting a message on linus-usb-devel! :-)
>
> It's important to stick with the same userspace components as much as
> possible during the testing, in case one of them turns out to be the
> guilty party rather than something in the kernel.
On Sat, 3 Mar 2007, Oliver Neukum wrote:
> Am Samstag, 3. März 2007 16:51 schrieb Alan Stern:
> > On Sat, 3 Mar 2007, Cristian Mammoli wrote:
> >
> > > Oliver Neukum ha scritto:
> > > > There's a very small chance that the compiler is to blame, but
> > > > it is far more likely that the phenomeno
Am Samstag, 3. März 2007 16:51 schrieb Alan Stern:
> On Sat, 3 Mar 2007, Cristian Mammoli wrote:
>
> > Oliver Neukum ha scritto:
> > > There's a very small chance that the compiler is to blame, but
> > > it is far more likely that the phenomenon itself is not fully repeatable.
> > > How often did
> So if you are accepting a firmware into the kernel, watch closely how
> it's being used. Tracking static symbols vs. buffer's content from
> request_firmware() can be harder, i think.
For things like USB the firmware question of security is pretty
irrelevant. If I can feed the device wrong firmw
On Sat, 3 Mar 2007, Laurent Pinchart wrote:
> Hi everybody,
>
> I'm trying to find a way to synchronise the Linux system clock with a device
> clock using the USB frame counter as a shared clock.
...
> I end up with three time sources: the device clock, the USB clock (through
> the
> SOF count
On Sat, 3 Mar 2007, Cristian Mammoli wrote:
> Oliver Neukum ha scritto:
> > There's a very small chance that the compiler is to blame, but
> > it is far more likely that the phenomenon itself is not fully repeatable.
> > How often did you try?
> >
> > Regards
> > Oliver
> >
> We
Am Samstag, 3. März 2007 13:43 schrieb Cristian Mammoli:
> Oliver Neukum ha scritto:
> > There's a very small chance that the compiler is to blame, but
> > it is far more likely that the phenomenon itself is not fully repeatable.
> > How often did you try?
> >
> > Regards
> > Oliver
On Sat, Mar 03, 2007 at 08:40:26AM +0100, Oliver Neukum wrote:
> Am Samstag, 3. M?rz 2007 01:29 schrieb Greg KH:
> > On Sat, Mar 03, 2007 at 01:27:07AM +0100, Oleg Verych wrote:
> > >
> > > If you can proof that it doesn't influence kernel's control above system
> > > hardware. Ironically such stu
Oliver Neukum ha scritto:
> There's a very small chance that the compiler is to blame, but
> it is far more likely that the phenomenon itself is not fully repeatable.
> How often did you try?
>
> Regards
> Oliver
>
Well, it happens every single time I boot (or reboot) the not
On Sat, 2007-03-03 at 11:44 +0100, Laurent Pinchart wrote:
> I'm trying to find a way to synchronise the Linux system clock with a device
> clock using the USB frame counter as a shared clock.
In a related scenario I have an USB device that periodically sends its
device clock over USB and I want
Hi everybody,
I'm trying to find a way to synchronise the Linux system clock with a device
clock using the USB frame counter as a shared clock.
My USB device has an internal clock, called the device clock. Its frequency is
reported in the USB descriptors. When streaming data (video), every vide
Am Samstag, 3. März 2007 10:07 schrieb Cristian Mammoli:
> On ven, 2007-03-02 at 02:08 +0100, Cristian Mammoli wrote:
> > On gio, 2007-03-01 at 22:14 +0100, Oliver Neukum wrote:
> > > > Most recent kernel where this bug did *NOT* occur: 2.6.17
> > >
> > > Very good. You are the first one to report
Am Freitag, 2. März 2007 17:03 schrieb Alan Stern:
> On Thu, 1 Mar 2007, Oliver Neukum wrote:
>
> > > Actually I had in mind something simpler, like getting rid of the
> > > GET_DESCRIPTOR_TRIES loop for i (or reducing it to one attempt using the
> > > new scheme and one attempt using the old sche
On Sat, 3 Mar 2007 08:24:00 +0100, Oliver Neukum wrote:
>Am Freitag, 2. März 2007 22:12 schrieb Adam J. Richter:
>> When I plug in a pl2303-based usb serial device, the device is
>> supposed to appear as /dev/tts/USB0 (character device 188, 0).
>> However, under kernels that I have tried from
Hi. I don't know if this is the correct list to hit, so please excuse me if
it's not.
I have a DLP-TILT with an FT232RL with PID 0xfbfa which I couldn't get working
with the ftdi_sio drivers. I emailed FTDI, and they suggested adding the PID
to ftdi_sio.h. I changed FTDI_SIO_PID to 0xfbfa to g
On ven, 2007-03-02 at 02:08 +0100, Cristian Mammoli wrote:
> On gio, 2007-03-01 at 22:14 +0100, Oliver Neukum wrote:
> > > Most recent kernel where this bug did *NOT* occur: 2.6.17
> >
> > Very good. You are the first one to report a working kernel version.
> >
> > Please post dmesg of a working
17 matches
Mail list logo
