Udev issues -- Maybe?
 

Ok so there are two examples here where I have had udev or the kernel or something just stick and not continue loading a device.

Example one is a usb game controller. In ARCH it worked fine but when I loaded up my LFS it would see the device when plugged in it would load the USB stuff but it would not for the life of me get it to assign it anything in /dev/input ? Nothing. After a Udev update and rebuild of kernel I decided to load up an older kernel and wham it started working again. Then when I loaded the newer kernel it started working again too?

Now I am trying to get a bluetooth mouse working and its doing something similar. In ARCH Linux it works fine, but in LFS it refuses to get anything past loading HID emulation. No output on dmesg or anything and there are no devices created in /dev/input. I have no idea whats wrong, I have checked the kernel and all the correct drivers and bluetooth stuff is there and the mouse connects and everything just no /dev/input devices.

Anyone have an idea what the hell is going on here, and why it works correctly in ARCH Linux but not in LFS/BLFS?

Update
 

So I got this working sort of yesterday. After a kernel compile and the addition of a few drivers that are not for my mouse but other off-brands it started working. Probably one of the other brands that is similar in model I'm not sure.

So now at least I get a /dev/input/mouse1 device. Now the problem is it wont work for more then half a second... It gets created i get about one movement out of the mouse and then nothing more. If i reboot the mouse it works again for half a second but then dies again. Im thinking its something with the d-bus permissions or something so im gonna go down that route and see whats up. If you got any thoughts on this new problem tho let me know.

So I finally got this fixed.

I checked the bluez web page once more and saw that there was a newer release of bluez out there. 4.96. After compile and install I tried once more and wallah I got my mouse working. Its noted that I did one final kernel compile and noticed that the mouse was getting detected as a bit of a different type now.

This has definitely been quite an adventure... and I come away with it in a bit of a bitter state. First off I had to use tools that are no longer provided by bluez to get the damn thing working and second I had to modify how it worked with d-bus because some things were wrongly done. It would be ideal for it to not use dbus or python but since the developer wanted to use these methods I can't really complain.

I would have like to have seen a solution that was written in C only and not using d-bus as I generally look down on the use of D-bus especially if it brings no benefit. However in this case dbus may work to an advantage as it allows intercommunication between pairing software and the device it self. I think the dev shouldn't hide the simple agent away in the source and not install it by default. But this is getting into more of bitching then giving good advice.

For anyone attempting this with semi newer hardware, PC or device, my only word of warning is don't expect to get it working after only a day of hacking away at it. Bluetooth although very old ( since 1999 ) is still very much ill supported in Linux, unless your working with distro or GUI stuff. But maybe this is a good thing maybe having less bluetooth devices is good and its better to work with RFI stuff anyway since the devices are getting smaller and more power efficient.

Who knows.