Okay, the ugly black space at the side of the image and the line can be
removed by changing the PAL horiz image offset.
In usbvision_set_input() if inside the PAL 'if' statement you change:
value[4] = 0x60;
to
value[4] = 0x42;
It should remove the line and most of the black gap. It should
Alan Stern wrote:
>It doesn't seem right to return a code indicating success when in fact we
>don't know whether the device reset worked or not.
>
Scsi layer will do it itself. There is no need to reimplement its logic.
If you take a look at scsi various controllers implementation of bus
reset
Okay I have this problem too. Its got to do with the sync detection of the
start of a line, and it being mis-detected.
I haven't been able to solve this problem yet, though I haven't had a close
look. There was a post earlier that using the CCIR sync codes fixed the
problem, however it didn'
> From: "Randy.Dunlap" <[EMAIL PROTECTED]>
> Date: Fri, 27 Sep 2002 22:45:45 -0700
> --- ./drivers/usb/core/usb.c.2539 Fri Sep 27 14:49:55 2002
> +++ ./drivers/usb/core/usb.c Fri Sep 27 22:35:30 2002
> +int nousb; /* Disable USB when built into kernel image */
> +
Greg,
Here's "nousb" for 2.4.39 if you want it.
It only applies to USB when built into a kernel image,
not as modules.
[Could be changed, but I didn't see a need for it.]
I'm working on some Documentation/kernel-parameters.txt
changes also, so I'll add this one when it's accepted.
~Randy
--- .
On Fri, Sep 27, 2002 at 09:51:32PM -0700, shino korah wrote:
> Hi,
>
>
> I'm developing a usb driver using usb-skelton.c.I
> have bulk_in and bulk_out end points . Now If i have
> one more bulk_out with address 0x0d Do I have to use a
> different urb structure? Or can I use the same urb
> stru
Hi,
I'm developing a usb driver using usb-skelton.c.I
have bulk_in and bulk_out end points . Now If i have
one more bulk_out with address 0x0d Do I have to use a
different urb structure? Or can I use the same urb
structure with only the address changed?
Thanks
Shino
_
> So, comments anyone? Is the locking here all done properly?
No, it's got a problem that's also found in the 2.5.39 code
(as I happened to notice). See excerpts below ... all paths
through the code should agree on this!
I suspect there should just be a lock guarding access to the
driver bound
This has minor usbcore cleanups:
DOC:
- the changes passing a usb_interface to driver probe() and disconnect()
weren't reflected in their adjacent docs. likewise they still said
it was possible to get a null usb_device_id (no more).
- the (root) hub API restrictions from rmk
Cameron Maxwell wrote:
>When your fiddling with the sync codes it changes where the decoder thinks the
>image starts. This happens to be inbetween YUV sequences. So if your
>changing the sync codes you also need to chagne the YUV order.
>
>In usbvision.c, usbvision_set_input() you'll see that
On Fri, Sep 27, 2002 at 05:02:35AM -0700, David Brownell wrote:
> Glad to see a version of this available.
>
>
> >+EXPORT_SYMBOL(usb_ifnum_to_ifpos);
> >+EXPORT_SYMBOL(usb_find_interface_driver_for_ifnum);
>
> Do we need to do this? Those functions are gone in 2.5,
> and today only usbfs uses
On Fri, 27 Sep 2002, Matthew Dharm wrote:
> A backport is planned. But there is a good deal of work to do on the 2.5
> branch before we're ready to backport fully.
>
> Someone (Alan?) did a backport of a pretty good snapshot. I don't remember
> the URL.
>
> Matt
>
> On Fri, Sep 27, 2002 at 02:0
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.611.1.9 -> 1.611.1.10
# drivers/pci/pc
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.611.1.8 -> 1.611.1.9
# drivers/usb/cor
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.611.1.7 -> 1.611.1.8
#drivers/base/c
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.611.1.6 -> 1.611.1.7
# drivers/usb/sto
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.611.1.4 -> 1.611.1.5
# drivers/usb/sto
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.611.1.5 -> 1.611.1.6
# drivers/usb/sto
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.611.1.3 -> 1.611.1.4
# drivers/usb/sto
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.611.1.2 -> 1.611.1.3
# drivers/net/ird
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.611.1.1 -> 1.611.1.2
# drivers/usb/usb
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.611 -> 1.611.1.1
# drivers/net/irda/
Hi,
This series includes some USB changes, and my changes to the driver core
to move /sbin/hotplug notification there, and out of the USB and PCI
cores. This patch has been previously posted and discussed.
Please pull from: bk://linuxusb.bkbits.net/linus-2.5
thanks,
greg k-h
drivers/base/M
Hi,
I have a problem to use USB keyboard and USB mouse as default input devices
for embedded system based on cs89712 running linux 2.4.6-rmk1-rayl1, the
following were done:
-using USB host controller SL811
-compiled USB HID (keyboard, mouse) support into kernel
-cat /dev/input/event0 can
> This raises a generally interesting question: When should a driver module
> be loaded?
For end users, whenever its hardware is connected.
That's the policy used by hotplug and by pcmcia_cs.
Applications that don't automatically notice the
new devices may need to get kicked too; having the
dri
A backport is planned. But there is a good deal of work to do on the 2.5
branch before we're ready to backport fully.
Someone (Alan?) did a backport of a pretty good snapshot. I don't remember
the URL.
Matt
On Fri, Sep 27, 2002 at 02:01:45PM +0400, Yuri Per wrote:
> David Brownell wrote:
>
>
On Fri, 27 Sep 2002, Yuri Per wrote:
> disconnect() and probe() should be simulated only when
> usb_reset_device() result was successful, as it is done now.
>
> The only change is that scsi layer now allowed to make later one more
> attempt to perform the request.
It doesn't seem right to return
On Fri, Sep 27, 2002 at 10:04:42AM +0200, Oliver Neukum wrote:
>
> Uh. I failed to send you one in this case.
> Is this the right one?
Nope, I already have that on. Here's the error message I get:
takepatch: can't find parent ID
[EMAIL PROTECTED]|ChangeSet|20020926091152|48468
i
disconnect() and probe() should be simulated only when
usb_reset_device() result was successful, as it is done now.
The only change is that scsi layer now allowed to make later one more
attempt to perform the request.
Yuri
Alan Stern wrote:
>On Fri, 27 Sep 2002, Yuri Per wrote:
>
>
>
>>F
Hi list,
I have this strange problem using my USB slide/film scanner
Nikon Coolscan LS40. The problem is present using both Sane
(frontend coolscan2.c) and Vuescan on the application side.
The problem causes a complete hang of the kernel USB scanner
module, reboot being the only known recovery (r
On Fri, 27 Sep 2002, Yuri Per wrote:
> Failed usb_reset_device() means only that reset is not yet completed.
This is not so. There are several possible error returns from
usb_reset_device() that can occur even before the reset has been
initiated. Furthermore, it's possible that the reset, once
Failed usb_reset_device() means only that reset is not yet completed.
If we will return success from bus_reset(), scsi layer will wait for 5
seconds during which device will probably reconnect.
--- a/drivers/usb/storage/scsiglue.cFri Sep 27 18:20:19 2002
+++ b/drivers/usb/storage/scsiglue.c
Glad to see a version of this available.
> +EXPORT_SYMBOL(usb_ifnum_to_ifpos);
> +EXPORT_SYMBOL(usb_find_interface_driver_for_ifnum);
Do we need to do this? Those functions are gone in 2.5,
and today only usbfs uses them in 2.4 ... I don't see a
reason to export them or include them in .
- Da
> After upgrading from clean 2.5.38 to version from Greg's BitKeeper
> repository I havn't seen kernel hangs any more. Drive works without
> problems. There are several failed requests in log which was correctly
> aborted and retried.
>
> Are there any plans to backport usb-storage changes to
David Brownell wrote:
> Err, this morning Yuri sent a trace on 2.5.38 which showed an INQUIRY
> issue.
>
> Matthew Dharm wrote:
>
>> 2.5 fixes this -- we changed the SCSI layer INQUIRY logic to act more
>> like
>> windows.
>
This 255-byte INQUIRY came from user-mode program ioctl, it's not a
k
Am Freitag, 27. September 2002 07:11 schrieb Greg KH:
> On Thu, Sep 26, 2002 at 12:04:02PM +0200, Oliver Neukum wrote:
> > Hi,
> >
> > this fixes an unplugging problem and an SMP deadlock.
> > It's for 2.4. Please apply.
>
> Applied, but by using the patch, I could not do a 'bk receive' on the
> c
36 matches
Mail list logo
