| View previous topic :: View next topic |
| Author |
Message |
Zubzub
Tux's lil' helper
Joined: 14 Jun 2006
Posts: 91
Location: ::1
|
 Posted: Wed Nov 15, 2006 12:43 pm Post subject: |
 |
|
| yes that would be nice, you can send it to DeRijcke.Erik@Gmail.com if you like. |
|
| Back to top |
|
 |
ColiverHB
n00b
Joined: 20 Apr 2006
Posts: 31
|
| Posted: Wed Dec 06, 2006 8:18 pm Post subject: Has anyone? |
|
|
Has anyone gotten their Logitech diNovo Media Desktop Lazer Bluetooth dongle to actually use Bluetooth?
I've been trying for days and cant quite seem to get it to work, If anyone has, could you tell me how?
It just doesn't seem to show up in hciconfig after I run hid2hci, and its getting very frustrating.
Thanks in advance. |
|
| Back to top |
|
|
Persona
n00b
Joined: 08 Sep 2006
Posts: 6
|
| Posted: Sun Jan 07, 2007 3:35 am Post subject: |
|
|
The way to get the Logitech diNovo Media Desktop Laser to operate in bluetooth mode is to build bluez-utils with the dinovo mdl patch as seen here.
Fortunately, for us, we do not have to generate and ebuild for this or try to patch it ourselves.
ebuild+patch (set the dinovo-mdl flag)
It is recommended that you use a portage overlay for this.
It is also recommended that you still patch your kernel.
This also may help. (I am not sure, but I have done it myself)
| trevorj wrote: |
This is ONLY for the Logitech DiNovo Media Desktop Laser !
| Code: | # Kernel patch
--- drivers/bluetooth/hci_usb.orig 2005-10-21 23:37:25.000000000 -0400
+++ drivers/bluetooth/hci_usb.c 2005-10-21 22:11:02.000000000 -0400
@@ -119,6 +119,9 @@
/* Kensington Bluetooth USB adapter */
{ USB_DEVICE(0x047d, 0x105d), .driver_info = HCI_RESET },
+ /* Logitech DiNovo Media Desktop Laser Transceiver for Bluetooth 2.0 */
+ { USB_DEVICE(0x046d, 0xc709), .driver_info = HCI_RESET },
+
/* ISSC Bluetooth Adapter v3.1 */
{ USB_DEVICE(0x1131, 0x1001), .driver_info = HCI_RESET }, |
|
|
|
| Back to top |
|
|
red-wolf76
l33t
Joined: 13 Apr 2005
Posts: 714
Location: Rhein-Main Area
|
| Posted: Sun Jan 07, 2007 5:12 pm Post subject: |
|
|
Kernel compilation after patching with the bluez-patch fails miserably already with sources newer than 2.6.17-5 (mm-sources)... I've confirmed this with gentoo-sources as well, so it doesn't appear to be a problem related to any particular kernel patchset.
Does this dinovo-mdl-patch work on the older v2.0 dinovo MediaDesktops (the ones without the laser mouse) as well? This
| Quote: | | This is ONLY for the Logitech DiNovo Media Desktop Laser ! |
appears to put a wrench in it...
_________________
0mFg, G3nt00 r0X0r$ T3h B1g!1111 
Use sane CFLAGS! If for no other reason, do it for the lulz! |
|
| Back to top |
|
|
Persona
n00b
Joined: 08 Sep 2006
Posts: 6
|
| Posted: Mon Jan 08, 2007 12:57 am Post subject: |
|
|
red-wolf76 check where /usr/src/linux links to. On my machine I noticed that I was linking to the oldest gentoo-sources (not 2.6.18-r6) I had that is what caused the patch to go so horribly(2.6.18 patch).
As for the patches mentioned the dinovo-mdl patch should not do anything since its is just telling the program the device names that it should be looking for to switch modes as for the kernel patch from trevorj I have no idea if that affects anything.
Just to be safe use the dinovo laser patches if you have it, otherwise disregard them. |
|
| Back to top |
|
|
Neskweek
n00b
Joined: 20 Jun 2004
Posts: 35
Location: Nantes - France
|
| Posted: Wed Feb 07, 2007 3:02 pm Post subject: |
|
|
Hi
It has been a long time since I didn't dropped by 
I must confessed that I moved my system to Kubuntu for a year before going back on my beloved Gentoo 
Yeah Why I tell you this ?
Because it makes 2 years since I wrotte this HOWTO but I've managed to get all my buttons works since only 3 days :/
So I've added my solution to the Howto on the first page and made some minor ajustment to the HOWTO.
I currently use :
2.6.18-gentoo-r6 kernel
2.6.18-mh8 patch from Bluez
bluez-libs 3.9
bluez-utils 3.9
I hope it will help
I'd just like to say two other things :
- the button part might work using the default bluez-libs/bluez-utils ebuilds. But if not, it works on my computer using the latest bluez sources (version 3.9)
- It seems that a patch had been realeased for bluez. This patch may allow sending text to the mediapad LCD. I didn't tried it yet (more info : http://linux.yes.nu/diNovo/ ) |
|
| Back to top |
|
|
red-wolf76
l33t
Joined: 13 Apr 2005
Posts: 714
Location: Rhein-Main Area
|
| Posted: Wed Feb 07, 2007 5:52 pm Post subject: |
|
|
| Persona wrote: | red-wolf76 check where /usr/src/linux links to. On my machine I noticed that I was linking to the oldest gentoo-sources (not 2.6.18-r6) I had that is what caused the patch to go so horribly(2.6.18 patch).
As for the patches mentioned the dinovo-mdl patch should not do anything since its is just telling the program the device names that it should be looking for to switch modes as for the kernel patch from trevorj I have no idea if that affects anything.
Just to be safe use the dinovo laser patches if you have it, otherwise disregard them. |
Hi Persona,
I did change the symlink to point to the newest sources but the patch would fail anyways. Besides, I'm using ~x86 mm-sources, so that may have something to do with it as well. Usually, latest installed kernel sources besides the .17 one I'm running is about one version ahead of the bluez patches, so I'm bound to be sort of piffled anyways...
I'll disregard the laser patches for now. As long as it works...
@Neskweek: Hi, and welcome back!
_________________
0mFg, G3nt00 r0X0r$ T3h B1g!1111
Use sane CFLAGS! If for no other reason, do it for the lulz! |
|
| Back to top |
|
|
Neskweek
n00b
Joined: 20 Jun 2004
Posts: 35
Location: Nantes - France
|
| Posted: Thu Feb 08, 2007 10:33 am Post subject: |
|
|
Well turns out I was too confident in my udev rules :/
Xorg doesn't like symlinks : it can't use them 
I have to find a better udev rule. I must find a way to create a real node /dev/input/mx900 (or /dev/mx900)
If you have any ideas ...
At that point I can create symlink(SYMLINK+="/dev/input/mx900"), but udev refuses to create a second node (NAME="/dev/input/mx900") pointing to the /class/input/inputNN/eventX device :/ . It seems he don't want to create a second node for an event. |
|
| Back to top |
|
|
Neskweek
n00b
Joined: 20 Jun 2004
Posts: 35
Location: Nantes - France
|
| Posted: Fri Feb 09, 2007 8:04 pm Post subject: |
|
|
Here are some info on the mouse :
cat /proc/bus/input/device
| Quote: |
I: Bus=0005 Vendor=046d Product=b001 Version=2200
N: Name="Logitech Bluetooth Mouse"
P: Phys=00:07:61:06:F7:31
S: Sysfs=/class/input/input64
H: Handlers=mouse2 event9
B: EV=f
B: KEY=ff0000 0 0 0 0 0 0 0 0
B: REL=103
B: ABS=300 0
|
udevinfo -n /dev/input/event9 -a
| Quote: |
Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/class/input/input64/event9':
KERNEL=="event9"
SUBSYSTEM=="input"
DRIVER==""
ATTR{dev}=="13:73"
looking at parent device '/class/input/input64':
KERNELS=="input64"
SUBSYSTEMS=="input"
DRIVERS==""
ATTRS{modalias}=="input:b0005v046DpB001e2200-e0,1,2,3,k110,111,112,113,114,115,116,117,r0,1,8,a28,29,mlsfw"
ATTRS{uniq}=="00:07:61:08:7C:E8"
ATTRS{phys}=="00:07:61:06:F7:31"
ATTRS{name}=="Logitech Bluetooth Mouse"
looking at parent device '/devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2.2/2-2.2:1.0/hci0/acl000761087CE8':
KERNELS=="acl000761087CE8"
SUBSYSTEMS=="bluetooth"
DRIVERS==""
ATTRS{address}=="00:07:61:08:7C:E8"
ATTRS{type}=="ACL"
looking at parent device '/devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2.2/2-2.2:1.0/hci0':
KERNELS=="hci0"
SUBSYSTEMS=="bluetooth"
DRIVERS==""
ATTRS{sniff_min_interval}=="80"
ATTRS{sniff_max_interval}=="800"
ATTRS{idle_timeout}=="6000"
ATTRS{inquiry_cache}==""
ATTRS{hci_revision}=="846"
ATTRS{hci_version}=="1"
ATTRS{manufacturer}=="10"
ATTRS{address}=="00:07:61:06:F7:31"
ATTRS{type}=="USB"
looking at parent device '/devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2.2/2-2.2:1.0':
KERNELS=="2-2.2:1.0"
SUBSYSTEMS=="usb"
DRIVERS=="hci_usb"
ATTRS{modalias}=="usb:v046DpC707d0846dcE0dsc01dp01icE0isc01ip01"
ATTRS{bInterfaceProtocol}=="01"
ATTRS{bInterfaceSubClass}=="01"
ATTRS{bInterfaceClass}=="e0"
ATTRS{bNumEndpoints}=="03"
ATTRS{bAlternateSetting}==" 0"
ATTRS{bInterfaceNumber}=="00"
looking at parent device '/devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2.2':
KERNELS=="2-2.2"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{configuration}==""
ATTRS{serial}=="06F731"
ATTRS{product}=="Logitech Bluetooth wireless hub"
ATTRS{manufacturer}=="Logitech"
ATTRS{maxchild}=="0"
ATTRS{version}==" 1.10"
ATTRS{devnum}=="5"
ATTRS{speed}=="12"
ATTRS{bMaxPacketSize0}=="64"
ATTRS{bNumConfigurations}=="1"
ATTRS{bDeviceProtocol}=="01"
ATTRS{bDeviceSubClass}=="01"
ATTRS{bDeviceClass}=="e0"
ATTRS{bcdDevice}=="0846"
ATTRS{idProduct}=="c707"
ATTRS{idVendor}=="046d"
ATTRS{bMaxPower}=="100mA"
ATTRS{bmAttributes}=="80"
ATTRS{bConfigurationValue}=="1"
ATTRS{bNumInterfaces}==" 3"
looking at parent device '/devices/pci0000:00/0000:00:1d.0/usb2/2-2':
KERNELS=="2-2"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{configuration}=="General Purpose USB Hub"
ATTRS{product}=="General Purpose USB Hub"
ATTRS{maxchild}=="2"
ATTRS{version}==" 1.10"
ATTRS{devnum}=="3"
ATTRS{speed}=="12"
ATTRS{bMaxPacketSize0}=="8"
ATTRS{bNumConfigurations}=="1"
ATTRS{bDeviceProtocol}=="00"
ATTRS{bDeviceSubClass}=="00"
ATTRS{bDeviceClass}=="09"
ATTRS{bcdDevice}=="0101"
ATTRS{idProduct}=="2036"
ATTRS{idVendor}=="0451"
ATTRS{bMaxPower}=="100mA"
ATTRS{bmAttributes}=="a0"
ATTRS{bConfigurationValue}=="1"
ATTRS{bNumInterfaces}==" 1"
looking at parent device '/devices/pci0000:00/0000:00:1d.0/usb2':
KERNELS=="usb2"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{configuration}==""
ATTRS{serial}=="0000:00:1d.0"
ATTRS{product}=="UHCI Host Controller"
ATTRS{manufacturer}=="Linux 2.6.18-gentoo-r6 uhci_hcd"
ATTRS{maxchild}=="2"
ATTRS{version}==" 1.10"
ATTRS{devnum}=="1"
ATTRS{speed}=="12"
ATTRS{bMaxPacketSize0}=="64"
ATTRS{bNumConfigurations}=="1"
ATTRS{bDeviceProtocol}=="00"
ATTRS{bDeviceSubClass}=="00"
ATTRS{bDeviceClass}=="09"
ATTRS{bcdDevice}=="0206"
ATTRS{idProduct}=="0000"
ATTRS{idVendor}=="0000"
ATTRS{bMaxPower}==" 0mA"
ATTRS{bmAttributes}=="e0"
ATTRS{bConfigurationValue}=="1"
ATTRS{bNumInterfaces}==" 1"
looking at parent device '/devices/pci0000:00/0000:00:1d.0':
KERNELS=="0000:00:1d.0"
SUBSYSTEMS=="pci"
DRIVERS=="uhci_hcd"
ATTRS{broken_parity_status}=="0"
ATTRS{enable}=="1"
ATTRS{modalias}=="pci:v00008086d000024D2sv00001043sd000080A6bc0Csc03i00"
ATTRS{local_cpus}=="3"
ATTRS{irq}=="20"
ATTRS{class}=="0x0c0300"
ATTRS{subsystem_device}=="0x80a6"
ATTRS{subsystem_vendor}=="0x1043"
ATTRS{device}=="0x24d2"
ATTRS{vendor}=="0x8086"
looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""
|
vi /dev/.udev/db/class@input@input64@event9
| Quote: |
N:input/event9
S:input/by-path/pci-0000:00:1d.0-usb-0:acl000761087CE8-event-
S:input/mx900
M:13:73
E:ID_VENDOR=Logitech
E:ID_MODEL=Logitech_Bluetooth_wireless_hub
E:ID_REVISION=0846
E:ID_SERIAL=Logitech_Logitech_Bluetooth_wireless_hub_06F731
E:ID_TYPE=generic
E:ID_BUS=usb
E:ID_PATH=pci-0000:00:1d.0-usb-0:acl000761087CE8
|
Using this rule :
KERNEL=="event*", ATTRS{uniq}=="00:07:61:08:7C:E8" , NAME="input/mx900"
the udevtest gives :
udevtest /class/input/input64/event9
| Quote: |
This program is for debugging only, it does not create any node,
or run any program specified by a RUN key. It may show incorrect results,
if rules match against subsystem specfic kernel event variables.
main: looking at device '/class/input/input64/event9' from subsystem 'input'
udev_rules_get_name: rule applied, 'event9' becomes 'input/event9'
run_program: 'usb_id -x'
run_program: '/lib/udev/usb_id' (stdout) 'ID_VENDOR=Logitech'
run_program: '/lib/udev/usb_id' (stdout) 'ID_MODEL=Logitech_Bluetooth_wireless_hub'
run_program: '/lib/udev/usb_id' (stdout) 'ID_REVISION=0846'
run_program: '/lib/udev/usb_id' (stdout) 'ID_SERIAL=Logitech_Logitech_Bluetooth_wireless_hub_06F731'
run_program: '/lib/udev/usb_id' (stdout) 'ID_TYPE=generic'
run_program: '/lib/udev/usb_id' (stdout) 'ID_BUS=usb'
run_program: '/lib/udev/usb_id' returned with status 0
run_program: 'path_id /class/input/input64/event9'
run_program: '/lib/udev/path_id' (stdout) 'ID_PATH=pci-0000:00:1d.0-usb-0:acl000761087CE8'
run_program: '/lib/udev/path_id' returned with status 0
udev_rules_get_name: add symlink 'input/by-path/pci-0000:00:1d.0-usb-0:acl000761087CE8-event-'
udev_device_event: device '/class/input/input64/event9' already in database, validate currently present symlinks
udev_node_add: creating device node '/dev/input/event9', major = '13', minor = '73', mode = '0600', uid = '0', gid = '0'
udev_node_add: creating symlink '/dev/input/by-path/pci-0000:00:1d.0-usb-0:acl000761087CE8-event-' to '../event9'
main: run: '/sbin/modprobe '
main: run: 'udev_run_devd input'
main: run: 'socket:/org/kernel/udev/monitor'
main: run: 'socket:/org/freedesktop/hal/udev_event'
|
|
|
| Back to top |
|
|
Neskweek
n00b
Joined: 20 Jun 2004
Posts: 35
Location: Nantes - France
|
| Posted: Mon Feb 12, 2007 2:38 pm Post subject: |
|
|
Ok I've spend some time this week end trying to create a real mx900 node. And I've succeed by adding this line in this file :
/etc/udev/rules.d/50-udev.rules
| Quote: |
# input devices
KERNEL=="mice", NAME="input/%k", MODE="0644"
KERNEL=="mouse*", NAME="input/%k", MODE="0644"
KERNEL=="event*", ATTRS{uniq}=="00:07:61:08:7C:E8" , NAME="input/mx900", MODE="0644"
KERNEL=="event*", NAME="input/%k", MODE="0644"
KERNEL=="js*", NAME="input/%k", MODE="664"
KERNEL=="ts*", NAME="input/%k", MODE="0600"
|
each time I connect the mouse now, I've got this node pointing to the mouse devices (and it works : cat /dev/input/mx900 produces the same event as the old /dev/input/eventX when I move the mouse or when I press buttons and all the info I've putted in my precedent post are just the same)
But (and this is a big but ...) Xorg can't use it :/
I get a :
/var/log/Xorg.0.log
| Quote: |
(II) evdev brain: Rescanning devices (1).
(EE) PreInit returned NULL for "MX900"
|
o_O
So at this point I'm kind of stuck 
I have no idea how to make Xorg (or the evdev brain ) using this node correctly ...
If I doesn't mistake, the mx900 node I've created should work just as the old eventX, or I missed something between the moment the node is created and the moment it is used by Xorg.
PS: Ok after some surfing I've found that https://forums.gentoo.org/viewtopic-t-465797-highlight-logitech+preinit+returned+null.html
In this thread it is explain that, just as I feared, evdev only checks devices that match the name event* :/
One way to pass this problem for the MX900 (I suppose) is to create a /dev/input/eventM (M standing for M for Mouse). Hopping this should trick the evdev driver. Or even freaky : create the mx900 node and simlink a /dev/event0 (what a pity )
If asking, using Option "Dev Name" "Logitech Bluetooth Mouse" in the Xorg Mouse section didn't worked in my previous attempt
I'll try again ... but with Option "Name" "Logitech Bluetooth Mouse" instead
We'll see but already I can tell that's an awful soution for our mouse : if the mouse hasn't been moved or paired before Xorg activation, Xorg will fail to start ... even with Option "AllowMouseOpenFail" "true" (odd)
Then there is one problem I anticipate :/ : this is the mx900 power saving mode...
How does Xorg will react ?
All I can tell for now is that even if the mouse is reactivated on the same event file (/dev/inpu/event6) after it went down , xorg fail to use it :/ you'll have to reboot X server ... |
|
| Back to top |
|
|
red-wolf76
l33t
Joined: 13 Apr 2005
Posts: 714
Location: Rhein-Main Area
|
| Posted: Mon Feb 12, 2007 8:38 pm Post subject: |
|
|
<professor-farnsworth>
Good news, everyone!
</professor-farnsworth>
Seems like the current 2.6.19-patch works with the latest 2.6.20-mm-rc6-mm3-sources! My DiNovo (v2.0 non-laser) boots fine in HCI. Without the patch, it was boot-protocol only. I'm no longer locked to a 2.6.17-kernel. Yay!
I wish I could help you, Neskweek, but I haven't much delved into evdev yet.
_________________
0mFg, G3nt00 r0X0r$ T3h B1g!1111
Use sane CFLAGS! If for no other reason, do it for the lulz! |
|
| Back to top |
|
|
Neskweek
n00b
Joined: 20 Jun 2004
Posts: 35
Location: Nantes - France
|
| Posted: Tue Feb 13, 2007 9:16 am Post subject: |
|
|
| red-wolf76 wrote: |
I wish I could help you, Neskweek, but I haven't much delved into evdev yet. |
Don't worry old thing
I've made it last evening :
So :
- Option "Name" "Logitech Bluetooth Mouse" :
This Option doesn't work AT ALL with our mouse => it returned a NULL Preinit in Xorg log... I suppose this option search the "Logitech Bluetooth Mouse" string using some sort of USB-related retreiving mecanism. Obviously it can't work with bluetooth mouse since they don't appear clearly on usb BUS. That's also why lomoco and other logitech based programs doesn't work with the mx900 : the device doesn't appear clearly on USB bus
-Option "Dev Name" "Logitech Bluetooth Mouse"
Here there is some interesting output (I'll put the /var/log//var/log/Xorg.0.log later I'm not at home)
Clearly, evdev finds several events related to our mouse. Here the problem is that evdev can't state which one to use ( or what to do with them ). The result is that no Pointer is returned and X crash ...
So here we are back on the udev rules that's our only hope:
We know now that :
- we must launch our rules BEFORE the udev general rules (/etc/udev/rules.d/50-udev.rules) => we create a file called /etc/udev/rules.d/40-dinovo.rules
- Our rules described before work ! That's granted. I mean we are able to create a node which is associated with the correct device we want to use and it product the good result... except for Xorg evdev driver, which is waiting for a node called /dev/input/eventX where X is an integer between 0 and 9 (yep tested ... X=10 oddly works when the system create a such devices but not working when you create it with a udev rule ... oO).
- symlinking the device doesn't work :
create a /dev/input/mx900 and symlink a /dev/input/eventX to it => Preinit NULL (odd)
create a symlink /dev/input/mx900 linked to a /dev/input/eventX generated automaticaly by udev general rules doesn't work
Considering all that, here is the rules I've made last evening :
/etc/udev/rules.d/40-dinovo.rules
| Quote: |
KERNEL=="event*", ATTRS{uniq}=="00:07:61:05:9a:b4" , NAME="input/event7", MODE="0644", SYMLINK+="input/keyboard"
KERNEL=="event*", ATTRS{uniq}=="00:07:61:06:8A:E1" , NAME="input/event8", MODE="0644", SYMLINK+="input/mediapad"
KERNEL=="event*", ATTRS{uniq}=="00:07:61:08:7C:E8" , NAME="input/event9", MODE="0644", SYMLINK+="input/mx900"
|
Here before udev.rules catch kernel events, we define our rules using MAC adresses of our devices, (they are written on the back of the mx900, keyboard and mediapad it's the numbers like 00:07:61:05:9a:b4).
As Xorg WANT nodes called /dev/input/eventX we gave him what it wants : we create 3 node : one per device.
Why ?
Because if we only do that for the mouse, if keyboard, mediapad & mx900 disconnect (power save mode) when they'll be reconnected we can't garanted that the keyboard, which had connect first hasn't use the event9 we have chosen to be the mx900 event :/
To counter that we decide to assign event to our keyboard and mediapad, to be sure they won't stole the mx900 node.
Oh why the symlink ?
It is just a visual help : a simple "ll /dev/input/*" will show which event are linked to which device (they can be ommited if you like)
Then, type
to make the changes effective
All we need to do next is to change our device line in /etc/X11/xorg.conf
| Quote: |
Section "InputDevice"
Identifier "MX900"
Driver "evdev"
Option "Device" "/dev/input/event9" # MX900 fixed event
Option "AbsoluteScreen" "0"
Option "Resolution" "800"
EndSection
|
Now restart your Xorg server and miracle it works !
Even better :
While your Xorg server is active try a :
| Quote: |
hidd --unplug [Mouse MAC Adress] # Unplug totaly the mouse
|
look in the /dev/input directory : you don't have a /dev/input/event9 => yeah that's normal
move the mouse : It's freezed ! => yeah that's normal too
Now reestablish a connection with your mouse :
| Quote: |
hidd --connect [Mouse MAC Adress] # Connect the mouse
|
look in the /dev/input directory : you have a /dev/input/mx900 linking to a /dev/input/event9 node
And the result waited for : move the mouse : it work !
Unpluging the mouse while Xorg and reconnecting it later works perfectly : the Xorg server hold steady To make it clearer (I don't know if my last sentence was clear enough :p) : The Power saving mode won't be a problem
I've tested those changes last evening for 5 hours => putting the mouse on dongle for battery recharging and take it back doesn't make the Xorg server loose the mouse.
Wait one hour until the mouse go to power saving mode doesn't make Xorg loose the mouse
That's a great step I'll make the changes in the howto on the first page
But there is still one thing annoying : at PC boot time : the mouse isn't connected ... and Xorg don't start, even with the
Option "AllowMouseOpenFail" "true"
|
|
| Back to top |
|
|
uagent
n00b
Joined: 17 Sep 2005
Posts: 61
Location: Flagstaff, AZ, USA
|
| Posted: Fri Apr 27, 2007 6:04 am Post subject: |
|
|
I have the Dell Bluetooth Wireless Keyboard and Mouse Bundle, and I've tried editing the hci_usb.c and hid2hci.c code to try and get it to pick up on my dongle's id's, but have had no success. I've read through this thread, and there doesn't seem to be much documentation on what to do when hid2hci and hidd don't pick up on the device.
What I think the issue is for those who aren't getting the patches to pick up on their devices is that there is a 4th device that isn't being picked up by the Gentoo kernel for whatever reason. The reason why I say this is that this is the lsusb from my Gentoo installation:
| Code: |
ssh linux # lsusb
Bus 002 Device 004: ID 046d:c70a Logitech, Inc.
Bus 002 Device 003: ID 046d:c70e Logitech, Inc.
Bus 002 Device 002: ID 046d:0b02 Logitech, Inc.
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
|
Now, the same box, from the Ubuntu 7.04 Feisty Fawn Live DVD:
| Code: |
ssh linux # lsusb
Bus 002 Device 005: ID 046d:c709 Logitech, Inc.
Bus 002 Device 004: ID 046d:c70a Logitech, Inc.
Bus 002 Device 003: ID 046d:c70e Logitech, Inc.
Bus 002 Device 002: ID 046d:0b02 Logitech, Inc.
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
|
I also noticed that hci_usb picked up on the "hidden" device in Ubuntu just fine (according to their buglists, they seem to have integrated the patch into their sources, which is fine, I don't mind adding one line). I'm just wondering how I can go about getting the kernel to pick up on the 4th device. I'm convinced at this point that the lack of detection is why my bluetooth dongle isn't working.
_________________
The Master of All Things That Don't Matter |
|
| Back to top |
|
|
djnauk
Apprentice
Joined: 11 Feb 2003
Posts: 183
Location: Caerphilly, Wales, UK
|
| Posted: Mon May 07, 2007 2:09 am Post subject: |
|
|
I've just re-installed my system and following instructions, and in HCI mode with the kbd driver I have the following symbol map (kernel 2.6.20-gentoo-r7 and xorg-7.1). This was manually created with xev and the keycodes DB:
// Logitech diNovo Media Desktop
partial alphanumeric_keys
xkb_symbols "dinovo" {
key <I2E> { [ XF86AudioLowerVolume ] };
key <I20> { [ XF86AudioMute ] };
key <I30> { [ XF86AudioRaiseVolume ] };
key <I29> { [ XF86AudioMedia ] };
key <I24> { [ XF86AudioStop ] };
key <I10> { [ XF86AudioPrev ] };
key <I19> { [ XF86AudioNext ] };
key <I22> { [ XF86AudioPlay, XF86AudioPause ] };
key <I5F> { [ XF86Standby ] };
key <I02> { [ XF86WWW ] };
key <I6C> { [ XF86Mail ] };
key <FK17> { [ XF86Search ] };
};
_________________
Jonathan Wright (Technical Director, JAB Web Solutions)
UK Hosting & Reseller Hosting from JAB Web Solutions |
|
| Back to top |
|
|
red-wolf76
l33t
Joined: 13 Apr 2005
Posts: 714
Location: Rhein-Main Area
|
| Posted: Mon May 14, 2007 9:25 pm Post subject: |
|
|
Grah! That'll teach me to upgrade packages!
Just upgraded all the bluez stuff to version 3.10 and I'm back in bluetooth hell! As far as I can tell, none of the scripts got plastered by the update, but it's still not working.
Remotely logging in through ssh and connecting stuff via hidd --search and pressing the buttons will work, but the bastard won't keep it on through a reboot.
I shallowly recall having to delete the device entries from /var/lib/bluetooth/*/hidd. Might that be it?
_________________
0mFg, G3nt00 r0X0r$ T3h B1g!1111
Use sane CFLAGS! If for no other reason, do it for the lulz! |
|
| Back to top |
|
|
djnauk
Apprentice
Joined: 11 Feb 2003
Posts: 183
Location: Caerphilly, Wales, UK
|
| Posted: Mon May 14, 2007 11:31 pm Post subject: |
|
|
| red-wolf76 wrote: |
Remotely logging in through ssh and connecting stuff via hidd --search and pressing the buttons will work, but the bastard won't keep it on through a reboot. |
IIRC, you can add '--connect bt:ad:dr:es:s1 --connect bt:ad:dr:es:s2 --connect bt:ad:dr:es:s3' to the HIDD command in the init script and it'll force the bluetooth subsystem to reconnect with the devices on login.
Note: I've never tried it, and only something I've seen written in passing (as I worked to get mine running), so it may or may not work, but could help!
_________________
Jonathan Wright (Technical Director, JAB Web Solutions)
UK Hosting & Reseller Hosting from JAB Web Solutions |
|
| Back to top |
|
|
red-wolf76
l33t
Joined: 13 Apr 2005
Posts: 714
Location: Rhein-Main Area
|
| Posted: Tue May 15, 2007 6:33 am Post subject: |
|
|
Ho-hum... For the time being, I reverted back to Version 2.25 of bluez-libs and bluez-utils and things are back to working again, boot-mode only though. I will try your suggestion and see if I can make it work.
After doing an hidd --search I've even seen them connect directly in bluetooth mode yesterday while fiddling about. Not reproducably, though... It's a horrid mess!
Also, I seem to have more dice using mm-sources-2.6.21-mm2 but that breaks my nvidia module. Crud!
_________________
0mFg, G3nt00 r0X0r$ T3h B1g!1111
Use sane CFLAGS! If for no other reason, do it for the lulz! |
|
| Back to top |
|
|
djnauk
Apprentice
Joined: 11 Feb 2003
Posts: 183
Location: Caerphilly, Wales, UK
|
| Posted: Tue May 15, 2007 10:51 am Post subject: |
|
|
| red-wolf76 wrote: | | Ho-hum... For the time being, I reverted back to Version 2.25 of bluez-libs and bluez-utils and things are back to working again, boot-mode only though. I will try your suggestion and see if I can make it work. |
Have you applied the bluez-patches to the kernel? Your keyboard should could out of boot mode then.
_________________
Jonathan Wright (Technical Director, JAB Web Solutions)
UK Hosting & Reseller Hosting from JAB Web Solutions |
|
| Back to top |
|
|
red-wolf76
l33t
Joined: 13 Apr 2005
Posts: 714
Location: Rhein-Main Area
|
| Posted: Tue May 15, 2007 11:41 am Post subject: |
|
|
Bluez-patches are currently at V2.6.20 whilst my latest kernel (mm-sources) is already at 2.6.21-r2. The old kernel I reverted to has the patches, I believe.
The funny thing is, that I've had it working under mm-sources without patches - and in bluetooth mode! Plus, when I tried an earlier patch on old sources I had lying around in a slot, it complained a lot about changes being already in there...
Unfortunately I'm nowhere near knowledgeable enough to check the source code myself. More of a "dumb user", I am...
_________________
0mFg, G3nt00 r0X0r$ T3h B1g!1111
Use sane CFLAGS! If for no other reason, do it for the lulz! |
|
| Back to top |
|
|
Persona
n00b
Joined: 08 Sep 2006
Posts: 6
|
| Posted: Sat May 26, 2007 5:21 am Post subject: |
|
|
New version of net-wireless/bluez-utils which is currently at 3.11.
Problems encountered:
when using the hid2hci command with a Logitech BT dongle causes kernel oops (I can confirm that for the Dinovo Laser set, as for the others I do not know about)
http://www.ussg.iu.edu/hypermail/linux/kernel/0703.3/0188.html
Also it has changed the way daemons/services are run.
check the ebuild for more info
http://gentoo-portage.com/AJAX/Ebuild/46592/View
I would suggest waiting a little longer until the bugs are worked out before upgraded to the newest version of bluez-utils. Since it is only a few days old at this point. |
|
| Back to top |
|
|
red-wolf76
l33t
Joined: 13 Apr 2005
Posts: 714
Location: Rhein-Main Area
|
| Posted: Sat May 26, 2007 9:29 am Post subject: |
|
|
You can compile bluez-utils-3.10.1 with the USE flages "old-daemons" for the time being and it will retain HIDD and so forth. Maybe that'll work on 3.11 too... Since those are deprecated however, it may be necessary to make a brand-new HOWTO for the new architecture in time.
Interestingly, when the devices have _not_ been paired (using HIDD), I can see and connect them under Gnome with bluez-gnome, but I can click on the authorization button all I want it won't authorize and I don't get to put in a PIN. (This happened both with my MediaPad and the MX900 Mouse! I needed the keyboard paired to get into gnome and had another wired mouse connected).
I am missing "input" in the services list of the dongle, though.  Maybe that's what's causing all this. Also, before bluez-gnome gets started, I guess it's going to be a pain to get the devices to work in boot-mode.
Why is Logitech making such great keyboards and then sucking up (effectively) to Mickey$haft by failing to provide any Linux stuff at all. Hell, even if they made only a debian RPM, someone could work with that and spread the goodness!
_________________
0mFg, G3nt00 r0X0r$ T3h B1g!1111
Use sane CFLAGS! If for no other reason, do it for the lulz! |
|
| Back to top |
|
|
red-wolf76
l33t
Joined: 13 Apr 2005
Posts: 714
Location: Rhein-Main Area
|
| Posted: Fri Jun 01, 2007 6:21 pm Post subject: |
|
|
Has anyone grokked the new bluez-dbus-API to the extent of getting things working yet?
I'll recompile stuff using old-daemons on sunday, since without HIDD, my setup's currently a dud and I can only use the diNovo stuff as expensive paperweights until I get this working.
EDIT: Ok, update time... I recompiled stuff with -old_daemons and used hidd --search to connect my devices (and they work in bluetooth mode) but with the keyboard, weirdness ensues! First of all, it's no longer reacting to the shift key, I have to engage CAPS_LOCK to receive upper case letters, but apparently the number row remains unaffected. Since I'm using special characters in my mail password, I can't check my mail! WTF?
Also, the keyboard and the mouse experience rather severe repetitions of keypresses and/or mousebutton clicks.
*groan*
_________________
0mFg, G3nt00 r0X0r$ T3h B1g!1111
Use sane CFLAGS! If for no other reason, do it for the lulz! |
|
| Back to top |
|
|
Diavolo
Apprentice
Joined: 09 Jan 2005
Posts: 151
|
| Posted: Wed Sep 12, 2007 7:51 pm Post subject: |
|
|
I have switched to bluetooth and everything seems to be connected fine. A hcitool scan finds Mouse and Keyboard but they don't work.
# hidd --search
bash: hidd: command not found
Any idea? What did I miss? I scanned with the command hcitool scan. |
|
| Back to top |
|
|
red-wolf76
l33t
Joined: 13 Apr 2005
Posts: 714
Location: Rhein-Main Area
|
| Posted: Fri Sep 14, 2007 10:07 am Post subject: |
|
|
| Diavolo wrote: | I have switched to bluetooth and everything seems to be connected fine. A hcitool scan finds Mouse and Keyboard but they don't work.
# hidd --search
bash: hidd: command not found
Any idea? What did I miss? I scanned with the command hcitool scan. |
Did you compile with USE="old-daemons"? Because hidd isn't (among others) included in the package by default any longer.
Incidentally, both keyboard, mouse and keypad of my suite are now working smoothly under Gnome with its resident bluetooth tool, but I still need to switch the receiver into hci-mode manually using a terminal in Gnome. The devices won't automagically connect if HID2HCI is called during boot, so I have to leave that turned off for stuff to work in GDM.
_________________
0mFg, G3nt00 r0X0r$ T3h B1g!1111
Use sane CFLAGS! If for no other reason, do it for the lulz! |
|
| Back to top |
|
|
Diavolo
Apprentice
Joined: 09 Jan 2005
Posts: 151
|
| Posted: Fri Sep 14, 2007 10:12 am Post subject: |
|
|
Thank you for your answer.
Do I need hidd to use bluetooth? I would recompile if yes.
When I switch manually with hid2hci or If I restart bluetooth, keyboard and mouse don't work any more. That's my problem...
| red-wolf76 wrote: | | Diavolo wrote: | I have switched to bluetooth and everything seems to be connected fine. A hcitool scan finds Mouse and Keyboard but they don't work.
# hidd --search
bash: hidd: command not found
Any idea? What did I miss? I scanned with the command hcitool scan. |
Did you compile with USE="old-daemons"? Because hidd isn't (among others) included in the package by default any longer.
Incidentally, both keyboard, mouse and keypad of my suite are now working smoothly under Gnome with its resident bluetooth tool, but I still need to switch the receiver into hci-mode manually using a terminal in Gnome. The devices won't automagically connect if HID2HCI is called during boot, so I have to leave that turned off for stuff to work in GDM. |
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Documentation, Tips & Tricks
