Hello,
we have a problem with some USB Bluetooth devices and it seems that the
Host Controller is the problem. Attached are my message with DEBUG
options enabled.
I have three USB devices which all uses the CSR Bluetooth chip.
Anycom USB dongle (same as that from COM One)
ELSA USB Dongle
Acer U
Hi Greg,
> What kernel version is this?
it is 2.4.19-pre9.
Regards
Marcel
---
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field a
Hi Greg,
I have updated my patch for disabling the bluetooth.o driver if the
Bluetooth subsystem is selected. I forgot to interface correctly with
the CONFIG_EXPERIMENTAL state of your driver.
Regards
Marcel
You can import this changeset into BK by piping this whole message to:
'| bk receive [p
Hi Greg,
this patch will disable the bluetty.o driver for 2.5.x if
the Bluetooth subsystem is selected, like it is now done
in 2.4.21-pre1.
Regards
Marcel
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
===
Hi Greg,
> As a side note, you might want to copy me on any patches you want me to
> apply, and not just send them to the mailing list. That way I am sure
> to see it :)
thanks for the info. I will take care of it the next time.
Regards
Marcel
--
Hi Andrew,
> Some bluetooth adapters return an incorrect number of sco packets in
> READ_BUFFER_SIZE. Fix it.
please hold this one off. We might not even need it. I am playing with
changes to the SCO flow control in the Bluetooth core. Lets see how far
they work before adding another quirk.
Reg
Hi Frederic,
> > + ep_dev->desc = &endpoint->desc;
> > + ep_dev->udev = udev;
> > + ep_dev->dev.devt = MKDEV(442, minor); // FIXME fake number...
> > + ep_dev->dev.class = ep_class->class;
> > + ep_dev->dev.parent = parent;
> > + ep_dev->dev.release = ep_devic
Hi Andrew,
> Some bluetooth adapters return an incorrect number of sco packets in
> READ_BUFFER_SIZE. Fix it.
>
> This is the worst possible way to fix it for several reasons:
> - this is not a generic fix, it has to me activated explicitely by the
> driver
>
> - this is not a driver-specific
Hi Sylvain,
> I've found a way to create an USB packets dumper for linux like USBSnoop in
> windows. Since I didn't found any on the Internet, I'd like to know if someone
> here is interrested. In this case I could submit a patch (or better) figure
> out
> how to create a compile option for the k
Hi Alex,
> here's the patch that adds support for USB transport layer via libusb to
> openobex library. The patch for the obex_test application is in the next
> message. Specification for these USB OBEX interfaces is available at
> http://www.usb.org/developers/devclass_docs
>
> Devices which su
Hi Brad,
> > the attached patch should do the renaming everywhere hid or hid.o was
> > mentioned. It also removes all references to *.o module names.
> How about the hiddev documentation?
I checked the hiddev.txt too, but I don't found any reference to the
hid.o/hid.ko kernel module.
Regards
Ma
Hi Greg,
> > the attached patch should do the renaming everywhere hid or hid.o was
> > mentioned. It also removes all references to *.o module names.
> >
> > Documentation/input/ff.txt |2 -
> > Documentation/input/input.txt| 70 +++
> > Docume
Hi Alan,
> I think this patch for the USB Bluetooth driver will prevent the problems
> you've been seeing. Let me know what happens.
why do we need a modification of the USB Bluetooth driver? In the case
of using an OHCI based card I don't see any oopses at URB unlink.
Regards
Marcel
-
Hi Alan,
> It really is an error in the Bluetooth driver. There's a difference
> between the OHCI and UHCI drivers that has the effect of making the error
> much less likely when using OHCI.
>
> In more detail:
>
> The code in hci_usb_unlink_urbs() calls usb_unlink_urb() to perform a
> synchro
Hi Greg,
> > many thanks for looking at the problem. I am not an expert when it comes
> > to USB internals, but from your explanation I ask myself why we don't
> > have an unlink function that will wait until the last reference to the
> > URB is gone. Why do we have to do it in the driver itself?
Hi Alan,
> I feel the same way. The API works as designed, but the design itself
> should be improved. A function very much like the one I added to your
> driver will probably go into the USB core, but I don't know when.
> Another change I would like to see would be to have separate
> usb_unli
Hi David,
> > also remember a long discussion about how we may better integrate the
> > SKB's as buffer for the URB's, but it seems that nobody has done any
> > code so far. Are there any improvements in 2.6 that I am not aware of?
>
> I thought the resolution was that the bluetooth code should
>
Hi Sunil,
> When I connected the device I found that the probe function is called
> more than once. First time when the probe gets called it returns success
> with the number of bulk ins and outs as one. For the rest of the probe calls
> the bulk ins and outs are zero and the probe returns NULL an
Hi Alan,
> Your recent change to struct urb broke this function in the bluetooth
> driver. You know, I think usb_wait_for_urb() would make an excellent
> addition to usbcore. At some future time we could consider replacing
> synchronous unlink_urb with asynchronous unlink plus wait_for_urb.
Hi Greg,
> I know. I really hate what the Bluetooth driver does, and it's up to
> them to keep up with the changes in urbs due to them statically
> including a urb in their structures. That is what they agreed to when
> they did this a while ago. They are on their own here...
I know that Max a
Hi Greg,
> > I know that Max accepted this. So I also have to accept this, but this
> > doesn't count for the bfusb driver and inserting this hack prevents it
> > from oopsing on a UHCI controller, too.
>
> If you unlink the urb synchronously there should be no more problems, as
> Alan has fixed
Hi Oliver,
> I never looked seriously into it. Frankly, I find it confusing.
> But the dirty deed has been done. In fact you've approved it. So for 2.6
> we'll have to live with it. For 2.7 however, I am whetting my blades and
> will do emergency surgery on that driver, if it still should need it.
Hi Sunil,
> I am not completely sure what to use, can you let me know the source that
> works for bluetooth subsystem. Also can you give me some useful links
> relating to this issue.
the bluetty driver is a simple H2 to H4 converter and not a full
Bluetooth stack. The Bluetooth subsystem BlueZ u
Hi Greg,
> > +/* Ick. hiddev.h needs hid.h which needs input.h */
> > +#include
> > +#include <../drivers/usb/input/hid.h>
> > +#include
>
> Ick, does hiddev really need hid.h? If so, then we need to move it to
> include/linux/.
please redefine the ioctl's in fs/compat_ioctl.c and not move th
Hi Li,
> ==
> HID device simple driver interface
> ==
actually, I don't think we need a simple driver interface. We need a HID
driver interface in general. For example that you can register a driver
for one or multiple report ID and
Hi Dmitry,
> > This also means that the current keyboard and mouse
> > input devices will become a HID driver.
>
> Are you talking about usbmouse and usbkbd?
no, because if I recall correctly these are the boot mode drivers and
actually not used at all in any modern distribution.
For me the tas
Hi Jiri,
> > For me the task of converting HID reports into input events shouldn't be
> > actually the job of the HID core layer. My understanding is that the HID
> > core should support multiple transport layers. This is currently
> > achieved through the hid_device abstraction and used by the
Hi Li,
> --
> HID bus design overview.
> --
>
> A. Terms.
>
> The device of an driver: this mean the device that this driver matched.
>
> B. Design.
>
> As we discussed before, The entire HID subsystem is divid
Hi Dmitry,
> > The crucial thing here is that all reports but the ones that the driver
> > registered to will be processed in a standard way by the generic hid bus
> > layer, and those reports that the driver registered to will be ignored by
> > the layer, and passed for processing to the driver.
Hi Li,
> > JFYI the preliminary version of the hidraw interface is now in the
> > hid/usbhid git tree, and has also been in a few recent -mm kernels
> > already.
> >
> >
> The shadow driver support works now.
>
> The most largest problem is HID/Bluetooth can not work now. And, I have
> no an
Hi Jiri,
> > I like this idea, but it might not solve the case where you have parts
> > of the driver in kernel space and other parts in user space. For example
> > the control of a LCD display on the keyboard. However in most cases
> > registering drivers for a report id should be enough.
>
>
Hi Jiri,
> > What's the position of hidraw? It only is used when all other driver is
> > not usable on some report? or, it should be stick every working device.
>
> Current implementation (as you can see it in -mm or in my hid.git tree) is
> creating hidraw interface for just every HID device/i
Hi Luis,
> I'm developing a device that requires the Cable Association Model.
>
> The Cable-Based Associtiation Model (CBAF) extends the existing USB
> infrastructure.
> During the enumeration the host detects the device supports the Cable
> Association Framework and implements the Association
Hi Oliver,
> here's an additional device with the reset quirk.
>
> Regards
> Oliver
> Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
that patch doesn't apply since we already have this:
/* Dell laptop with Broadcom chip */
{ USB_DEVICE(0x413c, 0x8126), .dri
Hi Oliver,
> > > here's an additional device with the reset quirk.
> > >
> > > Regards
> > > Oliver
> > > Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
> >
> > that patch doesn't apply since we already have this:
> >
> > /* Dell laptop with Broadcom chip */
> > {
Hi Oliver,
> > > A user reported that his dongle needs a reset to work. A manual reset, the
> > > module option and that patch solved the issue.
> >
> > an manual reset is not possible. The HCI_RESET quirk only end up sending
> > HCI Reset as the first command. This actually only resets the Bluet
Hi,
after the discussion with Oliver at the LinuxTag last week, I started to
re-write the hci_usb driver to remove this ugly cruft around the URB
management in the driver. The basic driver (without ISOC support) is
working perfectly fine and thanks to the reference count of the URB and
the new USB
Hi,
> after the discussion with Oliver at the LinuxTag last week, I started to
> re-write the hci_usb driver to remove this ugly cruft around the URB
> management in the driver. The basic driver (without ISOC support) is
> working perfectly fine and thanks to the reference count of the URB and
> t
Hi Oliver,
> > an alternate way would be to extend the usb_kill_anchored_urbs() with
> > its own complete handler that gets called for every anchored URB. This
> > would make it possible to cleanup the allocated buffers. I attached a
> > patch for that, too.
>
> No, that would mean an URB could h
Hi Oliver,
> > > > an alternate way would be to extend the usb_kill_anchored_urbs() with
> > > > its own complete handler that gets called for every anchored URB. This
> > > > would make it possible to cleanup the allocated buffers. I attached a
> > > > patch for that, too.
> > >
> > > No, that w
Hi Pete,
> > static void urb_destroy(struct kref *kref)
> > {
> > struct urb *urb = to_urb(kref);
> > +
> > + if (urb->transfer_flags & URB_FREE_BUFFER)
> > + usb_buffer_free(urb->dev, urb->transfer_buffer_length,
> > + urb->transfer_buffer, urb->transfe
Hi Pete,
> > Perhaps you need to have two flags, for freeing unconditionally
> > and on condition of no errors having happened.
> > If you free unconditionally handling errors, eg. clearing a stall becomes
> > hard.
>
> This assertion makes no sense to me. URBs are not "freed" or "put" by
> magic
Hi Pete,
> > The usb_buffer_alloc() and usb_buffer_free() usage was taken from the
> > skeleton example driver. No idea if that is a good idea or not. I was
> > under the impression that using the provided helper function that take
> > care of DMA is a good thing.
>
> Just as I suspected.
>
> Yo
of an URB. It can be simply freed along with the
URB itself when the reference count goes down to zero. The new
flag URB_FREE_BUFFER enables this behavior.
Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]>
---
commit f4ff5d567226679db52ddfa87b4fac9b8b81b5f
Hi Greg,
> here is the patch to add the URB_FREE_BUFFER flag for freeing the
> transfer buffer together with the URB itself. Please apply.
anything wrong with this patch?
Regards
Marcel
-
This SF.net email is sponsored b
Hi Pete,
> > usb-add-urb_free_buffer-flag-and-the-logic-behind-it.patch
>
> > +++ b/drivers/usb/core/urb.c
> > @@ -13,6 +13,9 @@ static void urb_destroy(struct kref *kre
> > {
> > struct urb *urb = to_urb(kref);
> >
> > + if (urb->transfer_flags & URB_FREE_BUFFER)
> > + kf
usb_setup_{control,bulk,int}_urb helpers that will
allocate the transfer buffer and set URB_FREE_BUFFER flag for freeing
it when the reference count of an URB goes down to zero. This allows
an easy and simple construction of one-shot URBs.
Signed-off-by: Marcel Holtmann <[EMAIL PROTEC
Hi Greg,
> here is a patch that adds three URB setup helpers that will allocate the
> transfer buffer using kmalloc() and set the new URB_FREE_BUFFER flage to
> make it free together with the URB. Please apply.
while I was creating this patch, I was thinking about its usefulness. It
will make the
Hi Alan,
> > Sounds even more useful. Better abandon the halfway wrappers for the new
> > ones. Another thing I'd think may be useful is to take the endpoint
> > address instead of the pipe, because the pipe type is known to each
> > wrapper, right?
>
> I'm in favor of doing away with pipe values
Hi Oliver,
> > > Why do you care that much about the size of struct urb? There are a few
> > > hundred of these structures at most at any given time. I think we gain
> > > more
> > > in memory usage if we make using URBs easier, shrinking drivers' code.
> >
> > Firstly, we certainly are reasonin
Hi Stefan,
> Somebody at the Bluetooth Mailing List has made the interresting
> suggestion that the usb-hid mapper could do a fine job for the
> hci hid devices out there.
>
> He suggested to split off the hid stuff from the bus it's connecting.
>
> hid.o
> hid-usb.o
> hid-hci.o
>
>
> So befor
Hi,
I have to send a HID report to a device through hiddev. I know the
report ID and the content of the report. Can anyone show me some very
simple example code for doing this?
Regards
Marcel
---
This SF.net email is sponsored by: IBM Linux
Hi Ethan,
> > I have to send a HID report to a device through hiddev. I know the
> > report ID and the content of the report. Can anyone show me some very
> > simple example code for doing this?
>
> The reports are usually sent from the device to the host. I don't think it
> is in the specificat
Hi Alan,
> > Hi, one maconlinux session with the excellent linux kernel usbmon support
> > later, and I have my G4 powerbook's bluetooth adapter working.
> >
> > To recap: My new G4 powerbook has a bluetooth device that boots up in what
> > apppears to be a compatability mode - it looks exactly
Hi Greg,
> [PATCH] USB: Prevent hid-core claiming Apple Bluetooth device on new G4
> powerbooks
>
> To recap: My new G4 powerbook has a bluetooth device that boots up in
> what apppears to be a compatability mode - it looks exactly like an HID
> keyboard/mouse device.
>
> A special command sequ
Hi Greg,
> > > [PATCH] USB: Prevent hid-core claiming Apple Bluetooth device on new G4
> > > powerbooks
> > >
> > > To recap: My new G4 powerbook has a bluetooth device that boots up in
> > > what apppears to be a compatability mode - it looks exactly like an HID
> > > keyboard/mouse device.
> >
jor device nodes for character devices to the RFCOMM TTY
implementation of the Bluetooth subsystem.
Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]>
---
commit b11537c12ca162f731e3c6adba4580ef3c60c06e
tree a8340129dc9aad58515488fd35383cfdf3393fb4
parent 8a212ab6b8a4ccc6f3c3d1beba5f
etty-2.6.git
This will update the following files:
Documentation/devices.txt | 12 +-
Documentation/usb/bluetooth.txt | 44
2 files changed, 6 insertions(+), 50 deletions(-)
through these ChangeSets:
Marcel Holtmann <[EMAIL PROTECTE
Hi Greg,
> Here's a patch that adds Takahiro's USB over IP patch to the kernel
> tree. It's still a bit rough around the edges, so I'd like to get some
> comments and reviews from others. Especially those who know the USB HCD
> interface better than I (David and Alan...)
it would be great if th
Hi Greg,
> > > Here's a patch that adds Takahiro's USB over IP patch to the kernel
> > > tree. It's still a bit rough around the edges, so I'd like to get some
> > > comments and reviews from others. Especially those who know the USB HCD
> > > interface better than I (David and Alan...)
> >
> >
Hi Pete,
> I posted what I consider USBMon 0.3 to my homepage:
> http://people.redhat.com/zaitcev/linux/
>
> I never asked David Harding or Stephen Gowdy to hand it over, but I figure
> it was abandoned.
>
> The 0.3 release is, regretfully, rather useless. It reads events from
> usbmon (lowerca
Hi Pete,
I started to work on usbdump again and the usbmon text interface is
great, but it is a bad thing for usbdump to use. We really need a binary
interface for it. And especially with this comment in it:
/*
* No, we do not want arbitrarily long data strings.
* Use the binary interface if yo
Hi Pete,
> > Have you done any work on the binary interface for usbmon so far? I
> > would be perfect if you can add something like that and then I work on
> > the usbdump support for it.
>
> No, I haven't done anything tangible. I am not a big fan of abstract design,
> also I do not have a good
Hi Szilagyi,
> i cannot connect my SonyEricsson T68 on bluetooth
> root:~# rfcomm connect 0 00:09:D9:26:70:46 2
> (((on my phone accept and enter the pin:)))
> Can't connect RFCOMM socket: Resource temporarily unavailable
> root:~# (((I tried it as rfcomm connect 0 00:09:D9:26:70:46 1 as well)
Hi Alexander,
> there's now a webpage with information about using USB OBEX interfaces
> under Linux:
>
> http://members.dodo.com.au/~joaniemrc/nokia/Nokia-6670-USB.html
>
> Note that the obexftp patch offered from there is only a temporary hack,
> and I'm planning to write a proper patch when
Hi Greg,
> >Thanks for your reply ... I am thinking to write my own Bluetooth Stack
>
> Oh no, Linux already has about 5 of them at my last count...
actually I only count 2 at the moment. It is BlueZ and Affix, because
OpenBT and BlueDrekar are no longer maintained. What is the 5th?
> Why w
Hi Prakash,
> Is there any procedure to send packet from stack to tty driver ?... I
> didnt
> find any format and also flow ?...
if you use the bluetty driver you need to build the complete Bluetooth
stack by yourself. The format is HCI with H:4 transport protocol. The
Bluetooth specificat
Hi Greg,
> > > Oh no, Linux already has about 5 of them at my last count...
> >
> > actually I only count 2 at the moment. It is BlueZ and Affix, because
> > OpenBT and BlueDrekar are no longer maintained. What is the 5th?
>
> I knew of one other closed source stack that I don't think ever becam
o not even need to read /proc/devices myself.
>
> Curiously enough, Marcel Holtmann argued for a device because he
> did NOT want to run udev. Funny how that works.
can't remember that I said that. My concern was that distros might not
compile debugfs and so usbmon would have bee
Hi Pete,
> Here's what I have right now. It pretty much takes shape, only mmap is
> remaining to be done. I'm basically going to copy your code there, only
> change it from 4-space to 1-tab formatting.
you don't have by any chance a version that applies cleanly against the
latest 2.6.19-rc tree f
Hi Alan,
> > > Here are a bunch of USB patches for 2.6.19.
> > >
> > > They contain:
> > > - new driver for usb debug device (client side only so far)
> > > - helper functions to find usb endpoints easier
> > > - minor bugfixes
> > > - new device support
> > > - usb core rework for auto
Hi Jiri,
> > about the USBHID part. Jiri Kosina is just about to finally split the
> > HID parser and make it available for Bluetooth and USB as an independent
> > subsystem. This might conflict with any autosuspend changes for the
> > USBHID. It might be better that this waits until Jiri's pat
Hi Dmitry,
> > > 1. Make hidinput_disconnect_core() be more robust, it can not
> > > break anything even failed to allocate device struct.
> > > 2. Thanks new input device driver API, we need not the extra code
> > > for support force-feed device yet, so say bye to
>
Hi Dmitry,
> > > I still have the same objection - the "simple'" code will have to be
> > > compiled into the driver instead of being a separate module and
> > > eventyally will lead to a monster-size HID module. We have this issue
> > > with psmouse to a degree but with HID the growth potential i
Hi Alan,
> Considering all the discussion whirling around about HID changes, it
> seemed like a good idea to let you know about some proposed patches coming
> up.
>
> They are below. The first addresses a problem that Pete has mentioned in
> the past: Some keyboards sometimes send more data th
Hi Duncan,
> > > So to my mind the importance of this patch is in improving correctness
> > > (lack of
> > > deadlocks) and responsiveness (newly plugged USB devices turn up at once,
> > > even
> > > if some other device is doing a long wait in its probe method), rather
> > > than
> > > perform
Hi Dmitry,
> > > > I still have the same objection - the "simple'" code will have to be
> > > > compiled into the driver instead of being a separate module and
> > > > eventyally will lead to a monster-size HID module. We have this issue
> > > > with psmouse to a degree but with HID the growth pot
Hi Jiri,
> This would be nice to merge, if noone has any major objections, and do
> other development on top of that.
> I am currently trying to set up an account and git tree for this at
> kernel.org ... request sent, waiting for reply :)
I can setup a tree for the merge. You simply have to c
Hi Linus,
> > Here are some patches that move the HID code to a new directory allowing
> > it to be used by other kernel subsystems easier.
>
> I pulled. However, I think the Kconfig changes are HORRIBLE.
>
> I don't understand why people don't use "select" more. Why should Kconfig
> ask for "G
Hi Pete,
> > I would like to know the current usbmon status. Is there any chance to
> > get the patch into a future kernel release ?!?
>
> Yes, there is. I was distracted by something shiny and also I've
> got a final on Friday... I wanted to clean the thing a little too,
> and write a passable d
Hi Paolo,
> > Can you send me your udev rule or a note however
> > you create the /dev/usbmonN?
>
> I create the device file with this script:
>
> #!/bin/sh
> mkdir /dev/usbmon
> mknod /dev/usbmon/1 c 253 1
> mknod /dev/usbmon/2 c 253 2
> mknod /dev/usbmon/3 c 253 3
> mknod /dev/usbmon/4 c 253 4
Hi Adam,
> >> I've developed an open-source python library for RFID, called RFIDIOt
> >> (http://rfidiot.org), which works with ACG serial RFID readers. I've
> >> just acquired the USB version of the reader and wanted to add support
> >> for it, but it isn't immediately recognised by the usbser
Hi Greg,
> They include a small number of fixes for some USB bugs, and some new
> device ids, all of the details are below. I've also disabled the USB
> multithreaded probe option, as it broke a number of people's machines.
what about the two pending patches to make device_move() working as
expe
Hi Greg,
> > > They include a small number of fixes for some USB bugs, and some new
> > > device ids, all of the details are below. I've also disabled the USB
> > > multithreaded probe option, as it broke a number of people's machines.
> >
> > what about the two pending patches to make device_mo
Hi Folks,
is there any reason why this patch is not yet submitted to Marcelo and
Linus? It is needed for switching a Logitech HID/Bluetooth dongle from
HID into HCI mode.
Regards
Marcel
> I've brought this up before and now that 2.6.0 is released, I'll bring it
> up again.
> Can we get the HID
Hi Vojtech,
> > is there any reason why this patch is not yet submitted to Marcelo and
> > Linus? It is needed for switching a Logitech HID/Bluetooth dongle from
> > HID into HCI mode.
>
> The part "I'm sure it breaks other devices" perhaps?
I am no HID expert so I can't judge this, but I haven'
Hi Philipp,
> This just happend on our IBM X31 running 2.6.1-vanilla when I disabled
> the internal bluetooth: (copied by hand from screen):
>
> usb 4-1: USB disconnected, address 2
> Unable to handle kernel paging request at virtual address 8234
> printing eip:
> c026d9cf
> *pde =
Hi Johannes,
> > this problem exists if you have compiled the HCI USB driver with the SCO
> > audio support. The workaround is to disable it. I haven't seen this bug
> > with an OHCI USB card, so I suspect a bug in the uhci_hcd driver, but I
> > am not sure.
>
> That address is very odd. It looks
Hi Vojtech,
> > I am no HID expert so I can't judge this, but I haven't had any problems
> > with this patch and my devices. Without this patch the hiddev interface
> > of the Logitech HID/Bluetooth dongle is not usable. The report we need
> > to send has 6 fields of one byte size, but through the
Hi Vojtech,
> And regarding the first patch - I'm still not convinced it's the right
> way to do it - James, can you send me a descriptor dump for that device?
> Maybe we're just misparsing the descriptor ...
what command should I use to provide you with the descriptor?
Regards
Marcel
-
Hi Vojtech,
> #define DEBUG and #define DEBUG_DATA in hid-core.c, then plug in the
> device, then dmesg.
>
> lsusb could possibly provide it, too.
I found no way to do it with lsub under 2.6.1, so here is the complete
dmesg part from the Logitech Bluetooth Hub. The important report id's
are 16 a
Hi Vojtech,
> Ok, this one looks OK. Applied together with your multi patch #2.
please also apply this to the 2.4 series and forward it to Marcelo.
Regards
Marcel
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on
Hi Tim,
> OK, I found uinput.c in kernel 2.6.0. Will it work under fedora's
> 2.4.22 kernel? If so, how do I go about building it?
it will be part of 2.4.25 final. Otherwise you can use my Bluetooth
patches from http://www.holtmann.org/linux/kernel/
Regards
Marcel
---
Hi Vojtech,
> > >Yes, but we probably want to fill all the usages[] entries we allocated.
> > >
> >
> > Good point. I realized I made an error anyways.
> > Here's a new one.
>
> Ok, this one looks OK. Applied together with your multi patch #2.
I haven't seen this patch in 2.6.3. Please submit i
Hi Tim,
> Is there any documentation, other than the code, on how to use the
> module uinput.c?
I don't think so. Somewhere I found an uinput sample application, but it
was a non working one. I used the uinput driver for the Bluetooth HID
daemon (in BlueZ utils2 CVS repository) and you can take
Hi Folks,
sorry for double posting, but accidentaly I sent this to the BlueZ
mailing list :(
My plan is to move the HID parser out of the USB subsystem and provide a
general HID parser implementation under drivers/hid/ which could then be
used by the USB and the Bluetooth subsystem drivers. To av
Hi Oliver,
> > In the end it should look like this:
> >
> > drivers/hid/hid.ko HID parser (input+hiddev+ff)
> > drivers/usb/input/usbhid.ko USB HID transport layer
> > net/bluetooth/hidp/hidp.ko Bluetooth HID protocol
> >
> > Comments?
>
> Sounds sensible. Why
Hi Vojtech,
> > > My plan is to move the HID parser out of the USB subsystem and provide a
> > > general HID parser implementation under drivers/hid/ which could then be
> > > used by the USB and the Bluetooth subsystem drivers. To avoid any naming
> > > conflict due and after the development I su
Hi Olaf,
> > > > > My plan is to move the HID parser out of the USB subsystem and provide a
> > > > > general HID parser implementation under drivers/hid/ which could then be
> > > > > used by the USB and the Bluetooth subsystem drivers. To avoid any naming
> > > > > conflict due and after the dev
Hi Vojtech,
> > I like to see this rename as soon as possible. So if nobody minds I send
> > a patch to LKML and ask Linus for inclusion.
>
> Go ahead, but also please patch all relevant documentation in the
> kernel.
the attached patch should do the renaming everywhere hid or hid.o was
mentione
1 - 100 of 119 matches
Mail list logo
