¼îÇθô¹«·á±¸Ãà,com/net/org±â°£¿¬Àå11ºÒ ¿ÜÈÀý°¨ÇսôÙ! [±¤°í]
À¥È£½ºÆúñ¸¸³»½Ã¸é ¼îÇθôÀ» ¹«·á·Î ±¸ÃàÇص帳´Ï´Ù.^^
¿Â¶óÀÎ/Ä«µå°áÁ¦ ¸ðµÎ°¡´ÉÇÕ´Ï´Ù.
ÀúÈñ¾÷ü´Â Àü¿ë¼± 200Mbps(T1¼ÓµµÀÇ 200¹è) È®ÃæÇÏ¿´½À´Ï´Ù.
±¹³»¿¡¼ °¡Àåºü¸¥ Àü¿ë¼±°ú ¾ÈÀü¼ºÀ¸·Î º¸´äÇÏ°Ú½À´Ï´Ù.
[¼îÇθô±¸Ãà]
http://www.bigmall.co.k
This fixes a bug in the audio driver which came from an
incorrect conversion from static to dynamic URB allocation.
It's against 2.5.5
I noticed this while trying to see exactly how ISO transfers
get used. The bug is that while originally the driver statically
allocated several structures {urb +
Vojtech Pavlik wrote:
>On Fri, Feb 22, 2002 at 01:58:32PM -0800, Mark McClelland wrote:
>
>>I originally wrote the decompressor for the OV518 using tables and a
>>single loop. Someone else rewote it with unrolled loops and without
>>tables, and it is 2.4 times faster now.
>>
>
>Hmm, I understan
Greg KH wrote:
>What this means is you didn't send me all of the changesets from when
>you cloned my tree to the one that you sent me.
>
>Can you either send me all of the changesets, or just send me a patch?
>
Here's a treediff between your tree and mine (which also doubles as a
patch). As you
Nemosoft Unv. wrote:
>Greetings,
>
>On Friday 22 February 2002 23:24, Mark McClelland wrote:
>
>There are additional problems; for example, the Philips decompressor
>routines need information on the exact command that was sent to the cam in
>order to initialize the decompressor properly. Pullin
Greetings,
On Friday 22 February 2002 23:24, Mark McClelland wrote:
> Randy.Dunlap wrote:
> >There was a lot of discussion about 1.5 years back that most of
> >the video decompression and format conversion stuff should be
> >done in userspace, and that maybe a video conversion library
> >should b
> I originally wrote the decompressor for the OV518 using tables and a
> single loop. Someone else rewote it with unrolled loops and without
> tables, and it is 2.4 times faster now.
Thats pretty much the same as video playback people have found. A modern
processor can do YUV->RGB computation f
On Thu, Feb 21, 2002 at 08:30:48PM -0800, David Brownell wrote:
> Hi Greg,
>
> This is another API cleanup patch. It's against 2.5.5:
I did make this minor change on top of your patch. I don't like to have
header files that include other header files :)
So I put back the #include in hcd.c an
On Fri, Feb 22, 2002 at 01:29:25PM -0800, David Brownell wrote:
> Here's a minor update to the EHCI interrupt scheduler,
> recordin the bandwidth used by an URB for usbfs.
>
> Please apply to both 2.5.5 and 2.4.19-pre.
Applied, thanks.
greg k-h
___
[
> However, a grep of drivers/usb/*.c tells me that most drivers
> ignore the return value of usb_unlink_urb(). That's quite a lot of
> potential bugs ... there's a race. Happens on MP systems (CPU
> #1 is running the HCD's interrupt handler, which calls the urb's
> driver completion callback; C
__
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listi
__
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listi
Randy.Dunlap wrote:
>There was a lot of discussion about 1.5 years back that most of
>the video decompression and format conversion stuff should be
>done in userspace, and that maybe a video conversion library
>should be supplied to make it easier on apps.
>
>Isn't that still desirable?
>
Desira
On Fri, Feb 22, 2002 at 01:58:32PM -0800, Mark McClelland wrote:
> It could be done with tables, but it would be significantly slower. In
> fact, you can tell from the "j=0" comment that it was probably a loop at
> one time. No self respecting iDCT is written that way :)
>
> I originally wrote
It could be done with tables, but it would be significantly slower. In
fact, you can tell from the "j=0" comment that it was probably a loop at
one time. No self respecting iDCT is written that way :)
I originally wrote the decompressor for the OV518 using tables and a
single loop. Someone els
Here's a minor update to the EHCI interrupt scheduler,
recordin the bandwidth used by an URB for usbfs.
Please apply to both 2.5.5 and 2.4.19-pre.
- Dave
ehci-0222.patch
Description: Binary data
Hello Greg,
> Well I messed up in giving the auerswald driver the minor numbes 80-95.
> Turns out those minors are used by the dc2xx driver :)
>
> AND the hiddev driver uses minor 96-111, which was not documented
> _anywhere_ (in dc2xx's defence, the linux-usb.org site did show this.
> now it is
Well I messed up in giving the auerswald driver the minor numbes 80-95.
Turns out those minors are used by the dc2xx driver :)
AND the hiddev driver uses minor 96-111, which was not documented
_anywhere_ (in dc2xx's defence, the linux-usb.org site did show this.
now it is updated with the correct
On Thu, Feb 21, 2002 at 08:30:48PM -0800, David Brownell wrote:
> Hi Greg,
>
> This is another API cleanup patch. It's against 2.5.5:
Looks good, applied.
> There are still a few functions in usb.c that aren't for
> general driver use. They're mostly for enumeration,
> in areas where the hub
On Friday 22 February 2002 17:47, Greg KH wrote:
> On Fri, Feb 22, 2002 at 08:21:44AM -0800, Randy.Dunlap wrote:
> > There was a lot of discussion about 1.5 years back that most of
> > the video decompression and format conversion stuff should be
> > done in userspace, and that maybe a video conve
On Thu, Feb 21, 2002 at 10:49:10PM -0800, Mark McClelland wrote:
> This changeset adds the OV511 decompression module to 2.5.x and updates
> the OV511 Config.help.
I'll respond to the whole list, as you aren't the first person I've had
problems with receiving changesets from.
I get the followin
Hello David,
> API CHANGE #1: Let INTR completion handlers change
> the transfer_buffer_length. A value of "-1" (it's not
> a size_t!!) would mean "don't transfer anything". Any
> other value, up to the maximum allowed by the endpoint
> descriptor (which is what would control the bandwidth
> a
> I thought that color conversion wasn't allowed, but decompression has to
> be done by the individual drivers as each device has a different
> compression format. And we can't expect all of the different video apps
> to pick up all of the different decompression functions.
Basically you want to
On Fri, Feb 22, 2002 at 08:21:44AM -0800, Randy.Dunlap wrote:
> There was a lot of discussion about 1.5 years back that most of
> the video decompression and format conversion stuff should be
> done in userspace, and that maybe a video conversion library
> should be supplied to make it easier on a
On Fri, 22 Feb 2002, Vojtech Pavlik wrote:
| On Thu, Feb 21, 2002 at 10:49:10PM -0800, Mark McClelland wrote:
| > This changeset adds the OV511 decompression module to 2.5.x and updates
| > the OV511 Config.help.
| >
| > I've made sure that it builds, but since 2.5.5 doesn't compile for me it
| >
On Thu, Feb 21, 2002 at 10:49:10PM -0800, Mark McClelland wrote:
> This changeset adds the OV511 decompression module to 2.5.x and updates
> the OV511 Config.help.
>
> I've made sure that it builds, but since 2.5.5 doesn't compile for me it
> isn't tested. It's known to work under other kernels
> Von: Greg KH [mailto:[EMAIL PROTECTED]]
> I'd recommend 2.4.17 at the least, with 2.4.18-rc2 the best
> bet. Using
> the 2.4.18-rc2-gregkh-1 patch I sent out would be even better :)
Thank You. I'll give one of them a try.
Siegfried.
___
[EMAIL PR
27 matches
Mail list logo
