G'day,
While backporting some stuff from 2.5/linuxconsole CVS to 2.4, I came across
some changes to the way the dev->name string is calculated. I think it can
lead to a one character overflow.
This is an extract from hid-core.c:usb_hid_configure()
hid->name[0] = 0;
if (!(buf
On Thu, 2002-05-02 at 22:59, Brad Hards wrote:
> On Fri, 3 May 2002 12:41, Marc Britten wrote:
> > Hi,
> >
> > I've been looking around but I have been unable to find mention of a
> > utility like USB snoop for Linux. I've been using USB snoop to snag data
> > in MS Windows to work on figuring out
On Fri, 3 May 2002 12:41, Marc Britten wrote:
> Hi,
>
> I've been looking around but I have been unable to find mention of a
> utility like USB snoop for Linux. I've been using USB snoop to snag data
> in MS Windows to work on figuring out a protocol.
You can just turn on the debugging options in
Hi,
I've been looking around but I have been unable to find mention of a
utility like USB snoop for Linux. I've been using USB snoop to snag data
in MS Windows to work on figuring out a protocol.
Now I have some of the protocol and I would like to test my knowledge
and theory's of how it works,
Aw crap!
I've got a series of patches against 2.5.8, and then this comes along
Greg, what's the best way to reconsile all of this? My tip is in the CVS
repository at sf.net...
The only reason I hadn't sent it was that my development machine is in
pieces
Matt
On Thu, May 02, 2002 at 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.566 -> 1.567
# drivers/usb/storage
# 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.571 -> 1.572
# drivers/usb/media/u
# 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.565 -> 1.566
# drivers/usb/serial/
# 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.568 -> 1.569
# drivers/usb/serial/
# 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.570 -> 1.571
# drivers/usb/image/m
# 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.572 -> 1.573
# drivers/usb/media/k
# 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.569 -> 1.570
# drivers/usb/serial/
# 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.567 -> 1.568
# drivers/usb/class/p
# 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.563 -> 1.564
# drivers/usb/net/peg
# 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.564 -> 1.565
# drivers/usb/host/oh
Pull from: bk://linuxusb.bkbits.net/linus-2.5
Documentation/usb/usb-serial.txt |6
drivers/scsi/sd.c |8
drivers/usb/class/printer.c| 13
drivers/usb/host/ohci-hub.c|4
drivers/usb/host/ohci-q.c | 12
drivers/usb/image/mdc800.c
On Fri, 3 May 2002 01:30, Manoj Sharma wrote:
> Sorry, I had really not understood what you meant by "hiddev".
I still don't think you understand what HID is - see below.
> The device is actually a panel having a LCD controller and a touchscreen
> (single device address). So I planned to provide
That's pretty much exactly what is being suggested. Leave the problem of
very strange devices to specific drivers. The us->extra is there to help
them out, but having arrays of pointers pushes more complexity into the
core of usb-storage when it should be in the device-specific drivers.
Matt
O
On Thu, May 02, 2002 at 02:50:39PM +0100, Simon Evans wrote:
>
> This patch makes usbvideo.c use the correct value of USBVIDEO_NUMFRAMES.
> A few places in the code assumed it was 2. This patch was tested with
> USBVIDEO_NUMFRAMES = 2,3,4,8,11,32
Applied, thanks.
greg k-h
p.s. Thanks for send
On Thu, May 02, 2002 at 12:22:47PM +0100, Simon Evans wrote:
>
> This patch makes usbvideo_register take a usb_device_id argument which it
> can then pass to usb_register via the struct usb_device. Currently it passes
> NULL.
I made one small change to this patch:
> + struct usb_device_id i
From: Matthew Dharm <[EMAIL PROTECTED]>
> But us->extra can only hold a single value.
This isn't really true. If you implement them as different LUNs on the
same unit, the SCSI layer won't allow them to both have a command active
at once.
Besides, the control thread for
On Fri, May 03, 2002 at 12:15:54AM +0200, [EMAIL PROTECTED] wrote:
> That does not work, since both cf and sm can be active simultaneously.
> But us->extra can only hold a single value.
This isn't really true. If you implement them as different LUNs on the
same unit, the SCSI layer won't allow t
i.e. you want to use datafab.c for lun #0, but you own driver
for lun #1..3 ?
My own driver for lun 1, yes.
And in another device precisely the reverse, datafab.c for lun #1
and my own driver for lun #0.
[The thing I mentioned is two USB devices with two luns each,
not one device with fo
On Wed, May 01, 2002 at 06:24:34AM -0700, David Brownell wrote:
> Can you merge this to Marcelo's tree? It's against pre7.
Applied, thanks.
greg k-h
___
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the h
On Wed, May 01, 2002 at 07:48:07AM -0700, David Brownell wrote:
> Can you merge this to Marcelo's tree? It's against 2.4.19-pre7
> plus the ehci24-0417 patch you submitted.
Applied, thanks.
I'll wait for -pre8 to come out before sending Marcelo any more USB
patches (as per his recommendation.)
From: Matthew Dharm <[EMAIL PROTECTED]>
If it provides multiple LUNs, then it must be using the 'standard'
interfaces. If that's the case, none of the 'standard' class drivers use
the us->extra pointer.
I'm confused.
I have several devices here that read smart media.
All of
On Thu, May 02, 2002 at 01:08:47AM +0200, Oliver Neukum wrote:
> Hi,
>
> looking through printer.c in preparation for shifting devfs
> support to usbcore I noticed that printer advertises a device
> through devfs before it can be opened.
> As devfs, or more precisely devfsd can be used to trigger
>Of course I can have a special driver that knows that the SmartMedia
>extra data is at some given offset in us->extra, but otherwise
>this driver is completely identical to the driver of some other
>reader that only reads one type of card.
i.e. you want to use datafab.c for lun #0, but you own
If it provides multiple LUNs, then it must be using the 'standard'
interfaces. If that's the case, none of the 'standard' class drivers use
the us->extra pointer.
I'm confused.
Matt
On Thu, May 02, 2002 at 11:11:09PM +0200, [EMAIL PROTECTED] wrote:
> > All multi-function devices I've seen work
> All multi-function devices I've seen work in one of two ways:
> (1) They present a single USB interface, with multiple LUNs
Yes, that is what I am talking about.
A single us pointer, but multiple drivers, so that they cannot
all use us->extra. Nevertheless, all do use us->extra.
Andries
_
I'm not sure I understand your device.
All multi-function devices I've seen work in one of two ways:
(1) They present a single USB interface, with multiple LUNs
(2) They present multiple USB interfaces.
Are you saying you've now got a 3rd type of device, which presents all 6
media types on one U
On Thu, 2 May 2002, Juan Jose Natera Abreu wrote:
> First of all, please excuse my ignorance on the subject but the mailling
> list archives dont have a search feature.
Just search in google. Include linux-usb-devel in the search term.
> Now, what kind of facilities exist for user space applic
From: Matthew Dharm <[EMAIL PROTECTED]>
> 3. Presently usb-storage uses a single pointer us->extra
> with corresponding destructor us->extra_destructor.
> However, this does not really suffice. Multi-lun devices
> need one struct per lun, and such structs must be allocated
Am Donnerstag, 2. Mai 2002 20:27 schrieb Juan Jose Natera Abreu:
> Hi Guys,
>
> First of all, please excuse my ignorance on the subject but the mailling
> list archives dont have a search feature.
>
> I was reading the 2.5 TODO list and I saw that the dc2xx and rio500 were
> going to be removed fr
Hi Guys,
First of all, please excuse my ignorance on the subject but the mailling
list archives dont have a search feature.
I was reading the 2.5 TODO list and I saw that the dc2xx and rio500 were
going to be removed from the kernel tree in favor of user space support.
Now, what kind of facil
On Thu, May 02, 2002, Juan Jose Natera Abreu <[EMAIL PROTECTED]> wrote:
> First of all, please excuse my ignorance on the subject but the mailling
> list archives dont have a search feature.
>
> I was reading the 2.5 TODO list and I saw that the dc2xx and rio500 were
> going to be removed from
On Wed, 1 May 2002, Thomas Davis wrote:
>Johannes Erdfelt wrote:
>>
>> On Wed, May 01, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
>> >
>> > However, that's a UHCI-specific feature. Avoid it for
>> > drivers that you expect to work on other HCs.
>>
>> OHCI and EHCI are buggy then I guess. T
Am Donnerstag, 2. Mai 2002 14:20 schrieb Manoj Sharma:
> Brad,
>
> It is a HID device.
> I need to run X based applications over this LCD display.
> Since X server uses /dev/fb to write to the frame buffer, I thought of
> writing a frame buffer driver that reads the buffer (allocated by the
> driv
> This doesn't make any sense - perhaps you don't understand what I meant by
> "hiddev".
> Linux support is layered. The host controller talks to the PCI hardware. In
> turn, the device driver talks to the host controller. The device driver for
> HID devices is called hid. It exports two inte
I tried 2.4.19-pre7[*] and I still see the oops in the same place.
Allen
[*]At least I think I did: made a copy of the 2.4.18 source and applied the
patches from file patch-2.4.19-pre7.gz. Does this contain all the accumulated
changes up to pre7?
On Wednesday 01 May 2002 07:18 pm, David Brown
sorry to jump in here, but (without knowing any details about your
hardware - you didn't give any) are you sure you need to send actual
image data over the USB bus?
Most LCD displays (full displays, that is) that I've seen send the
actual image (screen) data over the normal (i.e. dedicated extre
This patch makes usbvideo.c use the correct value of USBVIDEO_NUMFRAMES.
A few places in the code assumed it was 2. This patch was tested with
USBVIDEO_NUMFRAMES = 2,3,4,8,11,32
cheers
si
drivers/usb/media/usbvideo.c | 50 +++
1 files changed, 27 inse
On Thu, 2 May 2002 23:02, Manoj Sharma wrote:
> On Thu, 2 May 2002, Brad Hards wrote:
> > Perhaps you write a userspace driver that talks to hiddev?
>
> No, I think I need to write a kernel module that talks to the hiddev. Then
> only I can use the /dev/fb from user space.
This doesn't make any se
On Thu, 2 May 2002, Brad Hards wrote:
> On Thu, 2 May 2002 22:20, Manoj Sharma wrote:
> > Brad,
> >
> > It is a HID device.
> > I need to run X based applications over this LCD display.
> The performance isn't going to be that great...
That's true.
> > Since X server uses /dev/fb to write to
On Thu, 2 May 2002 22:20, Manoj Sharma wrote:
> Brad,
>
> It is a HID device.
> I need to run X based applications over this LCD display.
The performance isn't going to be that great...
> Since X server uses /dev/fb to write to the frame buffer, I thought of
> writing a frame buffer driver that r
Brad,
It is a HID device.
I need to run X based applications over this LCD display.
Since X server uses /dev/fb to write to the frame buffer, I thought of
writing a frame buffer driver that reads the buffer (allocated by the
driver) and passes its contents to the the LCD controller over USB.
On Thu, 2 May 2002 21:45, Manoj Sharma wrote:
> Hi,
>
> I wanted to write driver for an USB based LCD display.
> Is there any USB based open source LCD display driver or frame buffer
> driver available?
What sort of device? Is it a HID device or a full video device?
I've done a driver (in userspac
Hi,
I wanted to write driver for an USB based LCD display.
Is there any USB based open source LCD display driver or frame buffer
driver available?
I will appreciate any pointer in this regard.
Thanks,
Manoj.
___
Have big pipes? So
This patch makes usbvideo_register take a usb_device_id argument which it
can then pass to usb_register via the struct usb_device. Currently it passes
NULL.
cheers
si
drivers/usb/media/ibmcam.c | 23 +--
drivers/usb/media/konicawc.c |3 ++-
drivers/usb/media/ultrac
49 matches
Mail list logo
