Linux From ScratchThis Forum is for the discussion of LFS.
LFS is a project that provides you with the steps necessary to build your own custom Linux system.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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?
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.
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.