Bug 114489 - [PATCH] Celsius Mobile H Bluetooth Keybord
[PATCH] Celsius Mobile H Bluetooth Keybord
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Zaitcev
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-01-28 12:27 EST by Thilo Müller
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-19 15:30:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
celsiusH touchpad synchronisation (765 bytes, text/plain)
2004-02-20 02:28 EST, Thomas Baumann
no flags Details
celsiusH patch (693 bytes, patch)
2004-02-25 04:57 EST, Thomas Baumann
no flags Details | Diff

  None (edit)
Description Thilo Müller 2004-01-28 12:27:59 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.4) Gecko/20030922

Description of problem:
I use a Fujitsu Siemens CELSIUS MOBILE H Notebook with integrated
Bluetouth Keybord.
Wit the standard i686 kernel the Keybord not work. The kernel isn`t
able to locate MAus and Keybord.

If i modify the Kernelsouce like this:

//usr/src/linux-2.4/drivers/usb/host

vi usb-uhci.c

//#define CONFIG_USB_UHCI_HIGH_BANDWIDTH


the kernel locates the Keybord and mouse in this way:

-
class: MOUSE
bus: USB
detached: 0
device: input/mice
driver: mousedev
desc: "Silitek Corp. BlueTooth Keyboard and Mouse"
usbclass: 3
usbsubclass: 1
usbprotocol: 2
usbbus: 3
usblevel: 1
usbport: 0
usbdev: 2
vendorId: 047b
deviceId: 0101
usbmfr: CST
usbprod: Blue Tooth Keyboard/Mouse
-class: KEYBOARD
bus: USB
detached: 0
driver: keybdev
desc: "Silitek Corp. BlueTooth Keyboard and Mouse"
usbclass: 3
usbsubclass: 1
usbprotocol: 1
usbbus: 3
usblevel: 1
usbport: 0
usbdev: 2
vendorId: 047b
deviceId: 0101
usbmfr: CST
usbprod: Blue Tooth Keyboard/Mouse
-
This looks OK. But now USB Stick runns verry slow. It means I need 3
min for 3mb.

What shout I do?


mfg

Thilo M�ller



Version-Release number of selected component (if applicable):
kernel-2.4.21-4.0.1.EL.i686.rpm

How reproducible:
Always

Steps to Reproduce:
1.Use the original Kernel from RedHat
2.
3.
    

Additional info:
Comment 2 Thomas Baumann 2004-02-20 02:28:22 EST
Created attachment 97851 [details]
celsiusH touchpad synchronisation

The problem also concerns to the mouse pointer of the Celsius Mobile H
Touchpad.
When applying the patch to the usb-uhci.c the Touchpad will be found but when
using gpm or X11 the mousepointer is not controllable.

When running the following script times then the touchpad synchronizes
correctly.

<-------------bof-->
#!/bin/sh
modprobe -r hid
sleep 1
moprobe hid
sleep 1
modprobe -r hid
sleep 1
moprobe hid
sleep 1
<-------------eof-->

// Thomas Baumann // tirili
Comment 3 Thilo Müller 2004-02-20 09:11:40 EST
A second way to sync the Touchpad is to power off/on the keyboard to
resync the touchpad.

Thilo Mueller
Comment 4 Thomas Baumann 2004-02-25 04:57:56 EST
Created attachment 98032 [details]
celsiusH patch

/* *_DEPTH_FIRST puts descriptor in depth-first mode. This has
 * somehow similar effect to FSBR (higher speed), but does not
 * slow PCI down. OTOH USB performace is slightly slower than
 * in FSBR case and single device could hog whole USB, starving
 * other devices.
 */
/* Turning off both CONFIG_USB_UHCI_HIGH_BANDWITH and *_DEPTH_FIRST
 * will lead to <64KB/sec performance over USB for bulk transfers targeting
 * one device's endpoint. You probably do not want to do that.
 */

Hope this helps. 

// Thomas Baumann
Comment 5 Thomas Baumann 2004-02-25 05:01:29 EST
Sorry, above patch was incomplete.

you need the following lines as well:

@@ -108,7 +108,7 @@
  * in FSBR case and single device could hog whole USB, starving
  * other devices.
  */
-#define USE_CTRL_DEPTH_FIRST 0  // 0: Breadth first, 1: Depth first
+#define USE_CTRL_DEPTH_FIRST 1  // 0: Breadth first, 1: Depth first
 #define USE_BULK_DEPTH_FIRST 0  // 0: Breadth first, 1: Depth first

 /* Turning off both CONFIG_USB_UHCI_HIGH_BANDWITH and *_DEPTH_FIRST
Comment 6 Thomas Baumann 2004-02-25 05:03:11 EST
Comment on attachment 98032 [details]
celsiusH patch

diff -ur -X dontdiff linux-2.4.21-1.1931.2.391.ent/drivers/usb/host/usb-uhci.c
linux-2.4.21-1.1931.2.391.u1/drivers/usb/host/usb-uhci.c
--- linux-2.4.21-1.1931.2.391.ent/drivers/usb/host/usb-uhci.c	2003-08-12
17:17:10.000000000 -0700
+++ linux-2.4.21-1.1931.2.391.u1/drivers/usb/host/usb-uhci.c	2003-08-12
17:54:08.000000000 -0700
@@ -97,7 +97,7 @@
  * is optimal, but PCI can be slowed down up-to 5 times, slowing down
  * system performance (eg. framebuffer devices).
  */
-#define CONFIG_USB_UHCI_HIGH_BANDWIDTH
+// #define CONFIG_USB_UHCI_HIGH_BANDWIDTH

 /* *_DEPTH_FIRST puts descriptor in depth-first mode. This has
  * somehow similar effect to FSBR (higher speed), but does not
@@ -97,7 +97,7 @@
  * is optimal, but PCI can be slowed down up-to 5 times, slowing down
  * system performance (eg. framebuffer devices).
  */
-#define CONFIG_USB_UHCI_HIGH_BANDWIDTH
+// #define CONFIG_USB_UHCI_HIGH_BANDWIDTH

 /* *_DEPTH_FIRST puts descriptor in depth-first mode. This has
  * somehow similar effect to FSBR (higher speed), but does not
@@ -108,7 +108,7 @@
  * in FSBR case and single device could hog whole USB, starving
  * other devices.
  */
-#define USE_CTRL_DEPTH_FIRST 0  // 0: Breadth first, 1: Depth first
+#define USE_CTRL_DEPTH_FIRST 1  // 0: Breadth first, 1: Depth first
 #define USE_BULK_DEPTH_FIRST 0  // 0: Breadth first, 1: Depth first

 /* Turning off both CONFIG_USB_UHCI_HIGH_BANDWITH and *_DEPTH_FIRST
Comment 7 Thilo Müller 2004-04-15 01:22:32 EDT
Hallo,

Thomas it helps not realy. It looks faster, but if you sync the 
devices 3 MB needs 5 min. 

Thanks Thilo
Comment 8 David Woodhouse 2004-05-24 08:40:32 EDT
If you install bluez-utils-2.7 and bluez-libs-2.7 from Rawhide and run
'hid2hci' does the USB HID device magically turn into a Bluetooth
adapter? If so, I suspect that doing this and then using the BT HID
support is the correct answer for 2.6.
Comment 9 Pete Zaitcev 2004-08-20 04:04:10 EDT
Wholesale Depth-first is not an option. Many other configurations
will break.

It looks as if HID loses packets, which is possible, I guess.
I could have scoped an implementation with some sort of better
queuing, but I would need the hardware and a lot of time.
This all looks rather hopeless...
Comment 10 Pete Zaitcev 2005-05-13 21:05:36 EDT
Is this configuration available for testing?
If not, what's the status? Does this work on RHEL 4?
Comment 11 RHEL Product and Program Management 2007-10-19 15:30:50 EDT
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
 
For more information of the RHEL errata support policy, please visit:
http://www.redhat.com/security/updates/errata/
 
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.

Note You need to log in before you can comment on or make changes to this bug.