4 ms·

You can see when hardware gets plugged in by running "dmesg" on the command line.

by akulbe 9y ago

krylon 9y ago
That does not always help, though. A while back, I tried to connect my Bluetooth headset to my low-end notebook. As far as dmesg could tell me, the Bluetooth chip was detected and worked just fine. But it did not detect any devices that were around. After the headphones failed, I tried again with my phone and a tablet (I have too many gadgets, I know) - the result was consistent throughout: The notebook did not discovery any pair-able devices. After about ten minutes of this, I decided I am too old for this crap and got my good notebook. This time, the notebook discovered the headphones, like it should, and it happily paired with the headphones, like it should, but every now and again, the Bluetooth connection just dropped, and the notebook could not re-discover the headphones until I rebooted it. dmesg was ominously silent about this, it merely pointed out that it had killed the Bluetooth daemon (but I suspect that was a result of the driver or the BT chip misbehaving). To be fair, otherwise both notebooks work perfectly fine, and I also have no idea if a "Driver Manager" would have helped me with either of these issues. And it is not a deal breaker for me either, because do not normally use my notebooks for anything that requires headphones. But I did run into problems that I suspect were caused either by the hardware or the driver, and dmesg did not help me at all. In case it matters, though, both notebooks run openSuse Tumbleweed, but I have a hunch neither of these problems is distro-specific. EDIT: OK, so this was not about enumeration. But still.
- ohazi 9y ago
  This is a problem with bluetooth, full-stop. The protocol is insane, and this sort of thing happens frequently on every platform.
  - com2kid 9y ago
    BT itself is NOT the problem. Some of the profiles are a bit odd, and others are downright eloquent and wonderful. The LE stuff is actually quite nice in places! BT chipsets on the other hand, are complete crap. And every single BT stack has its own mess of bugs and is 90% of an implementation of what the spec says, and each stack implements a slightly different 90%, and the remaining 10% is just random bugs.
    - ohazi 9y ago
      Strongly disagree. Every time I look into building anything with bluetooth I come to the same conclusion that the protocol is irredeemably awful. The fact that the massive pile of profiles essentially all need to be supported inside the chipset is what makes their firmware so buggy and unreliable. Software written by semiconductor manufacturers is famously bad, and the approach that bluetooth has taken basically asks them to do more of the firmware work, keep track of more application state, and never get their wires crossed. And because the chipset firmware is almost always a binary blob, system designers have no way to fix anything. Of course it's going to be a massive failure. What they should have done was built a dumb, encrypted pipe, and let downstream driver and application developers deal with the application-layer logic. Then the semiconductor manufacturers would only be responsible for a basic bulk transfer interface that's a lot harder to screw up. This is why wifi and ethernet and usb drivers tend to work reasonably well, and bluetooth drivers are an unreliable mess. I get why they did it... in the early days, prices for bluetooth chipsets varied depending on which profiles they supported. This was supposed to be a way for semiconductor companies to differentiate themselves in a world where they were increasingly viewed as commodity suppliers. But because they never bothered to invest in their firmware development (these companies have like 20 people working on chip design and verification and like 3 on firmware), they ended up making everything worse rather than adding value.
      - com2kid 9y ago
        AVRCP is quite eloquent. I get the feeling that whoever designed it is upset that it never got properly implemented or used. BTLE in its entirety is just simple. It is possible to read over the BTLE spec in a couple hours and understand it. (AVRCP can be read in half an hour tops, 15 minutes if you skim the same-y diagrams) BT SPP is, well, a glorified serial port, with all the advantages and disadvantages that entails. If you want a glorified pipe, BT SPP is where you go. You can actually use BT LE to do the same thing, at a much slower transfer rate. > wifi and ethernet and usb drivers tend to work reasonably well WiFi and USB drivers are also flaming piles of trash. Since 90% of USB use cases consist of either USB-HID or Mass Storage, there is less to get wrong. Do anything beyond that and you can easily find yourself SOL. And Wi-Fi drivers are complete crap. Power management sucks, Wi-Fi chips hard lock and somehow a watch dog timer never kicks in (how?), and they rarely give the speeds that they are supposed to. Intel had some Wi-Fi chip a few years back that, for a good 2 years after its release, it would randomly stop deciding to finding networks to connect to, until it was power cycled. After a couple of years on the market they finally released a firmware update. Don't get me wrong, Chipset BT Firmware is horrible. I've worked with vendors who obviously weren't using version control, subsequent patches would have regressions that made it apparent they had built today's patch off of old source code that predated the last patch they had sent us. Hilarity like that. But the OS side BT stacks also tend to suck. Then there is the driver for the BT chip, which can also suck. The actual BT standard itself, I would argue, isn't the largest part of what is wrong.
  - Mister_Snuggles 9y ago
    I have not experienced these problems. I have a Bluetooth mouse that I alternate between a Mac and a ThinkPad running OpenSUSE Tumbleweed. It’s flawless on both platforms. I have a Bluetooth keyboard paired to an iPad, again it works flawlessly. I have Bluetooth headphones that I’ve paired to a variety of computers and iDevices and they work flawlessly. In all honesty, I’m actually shocked at how well it all works given the horror stories I’ve heard.
    - noobermin 9y ago
      It really varies. My bluetooth works without incident with my linux machines, but I once spend almsot half an hour trying to pair with my macbook. I hardly use that macbook anymore because I ran into a myriad of problems. It still pisses me off to this day how people keep extolling macbooks while denigrating how linux is so unstable and broken because my experience has been exactly the opposite.
      - Mister_Snuggles 9y ago
        In my experience, my Macs and my OpenSUSE Tumbleweed ThinkPad are about on par in terms of how well they work. The Mac handles some things better, the ThinkPad handles other things better. Stability-wise, they’re all very solid machines. Looking at my co-workers with Windows laptops, I’m amazed at the amount of crap people are willing to put up with. They are so unreliable it’s unreal.
  - krylon 9y ago
    The same headphones will pair with my phone every time without hickups - well, maybe a couple of times, but considering that I use them daily, the problem rate is negligible. That phone is a (relatively) cheap Huawei phone running Android. I have no idea how far the Android kernel deviates from the regular Linux kernel, so maybe Huawei just put a real effort into writing good BT drivers (or the company that made the BT chip?). But the fact remains that with my phone and my tablet, Bluetooth pairing with the headphones works very well (= reliably). So while Bluetooth may suck in many ways I do not even begin to comprehend, in my case, I strongly suspect, the problem lies elsewhere.
- jraph 9y ago
  The problems might be due to interactions with wifi. On my laptop, I need to unload iwlwifi: modprobe -r iwlwifi and then reload it with these options: sudo modprobe iwlwifi bt_coex_active=0 swcrypto=1 11n_disable=8 for Bluetooth to work correctly. Without this, discovering Bluetooth devices often does not work correctly and when I manage to pair my headphones with the laptop, the connection is often lost when wifi is used.
  - mschuster91 9y ago
    You can persist the iwlwifi options so they get applied automatically, e.g. for Ubuntu: https://askubuntu.com/a/51250/777894 https://askubuntu.com/a/51250/777894
ktta 9y ago
udevadm is a better help. I use `udevadm monitor` to see what's happening when I'm plugging something in.
- dEnigma 9y ago
  That monitoring function is neat. I just tested it with my USB mouse.
- krylon 9y ago
  Thank you!
rwmj 9y ago
A better idea is to look at /sys/class and /sys/devices.
- tomc1985 9y ago
  All of the suggestions given work but none of them are a TreeView of every hardware node grouped by category then device. That said I much prefer doing I/O programming on Linux than Windows :)

You can see when hardware gets plugged in by running "dmesg" on the command line.

by akulbe 9y ago

You can see when hardware gets plugged in by running "dmesg" on the command line.

That does not always help, though. A while back, I tried to connect my Bluetooth headset to my low-end notebook. As far as dmesg could tell me, the Bluetooth chip was detected and worked just fine. But it did not detect any devices that were around. After the headphones failed, I tried again with my phone and a tablet (I have too many gadgets, I know) - the result was consistent throughout: The notebook did not discovery any pair-able devices. After about ten minutes of this, I decided I am too old for this crap and got my good notebook. This time, the notebook discovered the headphones, like it should, and it happily paired with the headphones, like it should, but every now and again, the Bluetooth connection just dropped, and the notebook could not re-discover the headphones until I rebooted it. dmesg was ominously silent about this, it merely pointed out that it had killed the Bluetooth daemon (but I suspect that was a result of the driver or the BT chip misbehaving). To be fair, otherwise both notebooks work perfectly fine, and I also have no idea if a "Driver Manager" would have helped me with either of these issues. And it is not a deal breaker for me either, because do not normally use my notebooks for anything that requires headphones. But I did run into problems that I suspect were caused either by the hardware or the driver, and dmesg did not help me at all. In case it matters, though, both notebooks run openSuse Tumbleweed, but I have a hunch neither of these problems is distro-specific. EDIT: OK, so this was not about enumeration. But still.

ohazi 9y ago
This is a problem with bluetooth, full-stop. The protocol is insane, and this sort of thing happens frequently on every platform.
- com2kid 9y ago
  BT itself is NOT the problem. Some of the profiles are a bit odd, and others are downright eloquent and wonderful. The LE stuff is actually quite nice in places! BT chipsets on the other hand, are complete crap. And every single BT stack has its own mess of bugs and is 90% of an implementation of what the spec says, and each stack implements a slightly different 90%, and the remaining 10% is just random bugs.
  - ohazi 9y ago
    Strongly disagree. Every time I look into building anything with bluetooth I come to the same conclusion that the protocol is irredeemably awful. The fact that the massive pile of profiles essentially all need to be supported inside the chipset is what makes their firmware so buggy and unreliable. Software written by semiconductor manufacturers is famously bad, and the approach that bluetooth has taken basically asks them to do more of the firmware work, keep track of more application state, and never get their wires crossed. And because the chipset firmware is almost always a binary blob, system designers have no way to fix anything. Of course it's going to be a massive failure. What they should have done was built a dumb, encrypted pipe, and let downstream driver and application developers deal with the application-layer logic. Then the semiconductor manufacturers would only be responsible for a basic bulk transfer interface that's a lot harder to screw up. This is why wifi and ethernet and usb drivers tend to work reasonably well, and bluetooth drivers are an unreliable mess. I get why they did it... in the early days, prices for bluetooth chipsets varied depending on which profiles they supported. This was supposed to be a way for semiconductor companies to differentiate themselves in a world where they were increasingly viewed as commodity suppliers. But because they never bothered to invest in their firmware development (these companies have like 20 people working on chip design and verification and like 3 on firmware), they ended up making everything worse rather than adding value.
    - com2kid 9y ago
      AVRCP is quite eloquent. I get the feeling that whoever designed it is upset that it never got properly implemented or used. BTLE in its entirety is just simple. It is possible to read over the BTLE spec in a couple hours and understand it. (AVRCP can be read in half an hour tops, 15 minutes if you skim the same-y diagrams) BT SPP is, well, a glorified serial port, with all the advantages and disadvantages that entails. If you want a glorified pipe, BT SPP is where you go. You can actually use BT LE to do the same thing, at a much slower transfer rate. > wifi and ethernet and usb drivers tend to work reasonably well WiFi and USB drivers are also flaming piles of trash. Since 90% of USB use cases consist of either USB-HID or Mass Storage, there is less to get wrong. Do anything beyond that and you can easily find yourself SOL. And Wi-Fi drivers are complete crap. Power management sucks, Wi-Fi chips hard lock and somehow a watch dog timer never kicks in (how?), and they rarely give the speeds that they are supposed to. Intel had some Wi-Fi chip a few years back that, for a good 2 years after its release, it would randomly stop deciding to finding networks to connect to, until it was power cycled. After a couple of years on the market they finally released a firmware update. Don't get me wrong, Chipset BT Firmware is horrible. I've worked with vendors who obviously weren't using version control, subsequent patches would have regressions that made it apparent they had built today's patch off of old source code that predated the last patch they had sent us. Hilarity like that. But the OS side BT stacks also tend to suck. Then there is the driver for the BT chip, which can also suck. The actual BT standard itself, I would argue, isn't the largest part of what is wrong.
- Mister_Snuggles 9y ago
  I have not experienced these problems. I have a Bluetooth mouse that I alternate between a Mac and a ThinkPad running OpenSUSE Tumbleweed. It’s flawless on both platforms. I have a Bluetooth keyboard paired to an iPad, again it works flawlessly. I have Bluetooth headphones that I’ve paired to a variety of computers and iDevices and they work flawlessly. In all honesty, I’m actually shocked at how well it all works given the horror stories I’ve heard.
  - noobermin 9y ago
    It really varies. My bluetooth works without incident with my linux machines, but I once spend almsot half an hour trying to pair with my macbook. I hardly use that macbook anymore because I ran into a myriad of problems. It still pisses me off to this day how people keep extolling macbooks while denigrating how linux is so unstable and broken because my experience has been exactly the opposite.
    - Mister_Snuggles 9y ago
      In my experience, my Macs and my OpenSUSE Tumbleweed ThinkPad are about on par in terms of how well they work. The Mac handles some things better, the ThinkPad handles other things better. Stability-wise, they’re all very solid machines. Looking at my co-workers with Windows laptops, I’m amazed at the amount of crap people are willing to put up with. They are so unreliable it’s unreal.
- krylon 9y ago
  The same headphones will pair with my phone every time without hickups - well, maybe a couple of times, but considering that I use them daily, the problem rate is negligible. That phone is a (relatively) cheap Huawei phone running Android. I have no idea how far the Android kernel deviates from the regular Linux kernel, so maybe Huawei just put a real effort into writing good BT drivers (or the company that made the BT chip?). But the fact remains that with my phone and my tablet, Bluetooth pairing with the headphones works very well (= reliably). So while Bluetooth may suck in many ways I do not even begin to comprehend, in my case, I strongly suspect, the problem lies elsewhere.
jraph 9y ago
The problems might be due to interactions with wifi. On my laptop, I need to unload iwlwifi: modprobe -r iwlwifi and then reload it with these options: sudo modprobe iwlwifi bt_coex_active=0 swcrypto=1 11n_disable=8 for Bluetooth to work correctly. Without this, discovering Bluetooth devices often does not work correctly and when I manage to pair my headphones with the laptop, the connection is often lost when wifi is used.
- mschuster91 9y ago
  You can persist the iwlwifi options so they get applied automatically, e.g. for Ubuntu: https://askubuntu.com/a/51250/777894 https://askubuntu.com/a/51250/777894

ktta 9y ago

udevadm is a better help. I use `udevadm monitor` to see what's happening when I'm plugging something in.

dEnigma 9y ago
That monitoring function is neat. I just tested it with my USB mouse.
krylon 9y ago
Thank you!

rwmj 9y ago

A better idea is to look at /sys/class and /sys/devices.

tomc1985 9y ago
All of the suggestions given work but none of them are a TreeView of every hardware node grouped by category then device. That said I much prefer doing I/O programming on Linux than Windows :)