[opensuse-kde3] Setting up BlueTooth with KDE3
I recently acquired a Matias BlueTooth keyboard that I can use to switch between my Linux and Mac computers. It works well with the Mac, but I haven't been able to get it to work with Linux. I'm using an Asus USB-BT400 USB adapter to connect it to my Asus H270M-Plus motherboard. I have installed the following packages from the KDE3 repository: libbluetooth3-4.19-19.1.x86_64 libbluetooth3-debuginfo-4.19-19.1.x86_64 kde3-kdebluetooth-1.0.8-180.8.x86_64 kde3-kdebluetooth-lang-1.0.8-180.8.noarch kde3-kdebluetooth-debugsource-1.0.8-180.8.x86_64 kde3-kdebluetooth-debuginfo-1.0.8-180.8.x86_64 bluez-test-4.19-19.1.x86_64 bluez-test-debuginfo-4.19-19.1.x86_64 bluez-compat-4.19-19.1.x86_64 bluez-compat-debuginfo-4.19-19.1.x86_64 bluez-4.19-19.1.x86_64 * bluez-debugsource-4.19-19.1.x86_64 bluez-debuginfo-4.19-19.1.x86_64 The following BlueTooth-related packages also are installed: bluez-qt-udev-5.21.0-12.1.x86_64 bluez-qt-imports-5.21.0-12.1.x86_64 bluedevil5-5.5.5-9.1.x86_64 bluedevil5-lang-5.5.5-9.1.noarch libgnome-bluetooth13-3.16.1-3.2.x86_64 When I try to configure Linux to communicate with my keyboard, using KInputWizard, it crashes as soon as I click on Add Device. Trace output from the KDE Crash Handler is as follows:
[Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [KCrash handler] #5 0x00007f999c44a0c7 in raise () from /lib64/libc.so.6 #6 0x00007f999c44b478 in abort () from /lib64/libc.so.6 #7 0x00007f999c1fe585 in ?? () from /lib64/libdbus-1.so.3 #8 0x00007f999c1f5151 in ?? () from /lib64/libdbus-1.so.3 #9 0x00007f999c1e6ae0 in dbus_message_new_method_call () from /lib64/libdbus-1.so.3 #10 0x00007f999e1aa08d in KBluetooth::DBusSignal::getBoolean (this=this@entry=0x8bcdc0, method=..., first_type=first_type@entry=0) at /usr/src/debug/kdebluetooth-1.0_beta8/kdebluetooth/libkbluetooth/dbussignal.cpp:468 #11 0x00007f999e1aa129 in KBluetooth::DBusSignal::getBoolean (this=this@entry=0x8bcdc0, method=...) at /usr/src/debug/kdebluetooth-1.0_beta8/kdebluetooth/libkbluetooth/dbussignal.cpp:455 #12 0x00007f999e1a57a8 in KBluetooth::Adapter::isPeriodicDiscovery (this=0x8bcdc0) at /usr/src/debug/kdebluetooth-1.0_beta8/kdebluetooth/libkbluetooth/adapter.cpp:424 #13 0x00000000004089ed in InputWizard::configNew (this=this@entry=0x7ffddcfc9320) at /usr/src/debug/kdebluetooth-1.0_beta8/kdebluetooth/kinputwizard/inputwizard.cpp:277 #14 0x000000000040baf0 in InputWizard::qt_invoke (this=0x7ffddcfc9320, _id=<optimized out>, _o=<optimized out>) at /usr/src/debug/kdebluetooth-1.0_beta8/kdebluetooth/kinputwizard/inputwizard.moc:156 #15 0x00007f999cea3e82 in QObject::activate_signal(QConnectionList*, QUObject*) () from /usr/lib/qt3/lib64/libqt-mt.so.3 #16 0x00007f999cea3f2e in QObject::activate_signal(int) () from /usr/lib/qt3/lib64/libqt-mt.so.3 #17 0x00007f999cecc631 in QWidget::event(QEvent*) () from /usr/lib/qt3/lib64/libqt-mt.so.3 #18 0x00007f999ce54cbb in QApplication::internalNotify(QObject*, QEvent*) () from /usr/lib/qt3/lib64/libqt-mt.so.3 #19 0x00007f999ce54ff5 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/qt3/lib64/libqt-mt.so.3 #20 0x00007f999d92c247 in KApplication::notify(QObject*, QEvent*) () from /opt/kde3/lib64/libkdecore.so.4 #21 0x00007f999ce03ac3 in QETWidget::translateMouseEvent(_XEvent const*) () from /usr/lib/qt3/lib64/libqt-mt.so.3 #22 0x00007f999ce03748 in QApplication::x11ProcessEvent(_XEvent*) () from /usr/lib/qt3/lib64/libqt-mt.so.3 #23 0x00007f999ce113f6 in QEventLoop::processEvents(unsigned int) () from /usr/lib/qt3/lib64/libqt-mt.so.3 #24 0x00007f999ce661a9 in QEventLoop::enterLoop() () from /usr/lib/qt3/lib64/libqt-mt.so.3 #25 0x00007f999cfd137f in QDialog::exec() () from /usr/lib/qt3/lib64/libqt-mt.so.3 #26 0x00000000004077cd in main (argc=1, argv=0x7ffddcfc9868) at /usr/src/debug/kdebluetooth-1.0_beta8/kdebluetooth/kinputwizard/main.cpp:65
(I have no idea how to even read this.) :-) * Please note that when I installed kde3-kdebluetooth, YaST required me to downgrade the bluez package from 5.35-1.1 to 4.19-19.1; maybe that has something to do with my problem. How should I proceed with this? Is it an incompatibility with udev, KDE4 or Plasma? (I'm trying hard to keep the newer KDEs off my system, but it's an uphill battle.) Or something else? Leslie
On 07/03/2017 08:24 PM, Leslie Turriff wrote:
When I try to configure Linux to communicate with my keyboard, using KInputWizard, it crashes as soon as I click on Add Device. Trace output from the KDE Crash Handler is as follows:
I would not use KInputWizard. The usb keyboard should not depend on KDE. Look at: https://wiki.archlinux.org/index.php/Bluetooth -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse-kde3+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde3+owner@opensuse.org
On 2017-07-06 19:44:55 David C. Rankin wrote:
On 07/03/2017 08:24 PM, Leslie Turriff wrote:
When I try to configure Linux to communicate with my keyboard, using KInputWizard, it crashes as soon as I click on Add Device. Trace output from the KDE Crash Handler is as follows:
I would not use KInputWizard. The usb keyboard should not depend on KDE. Look at:
https://wiki.archlinux.org/index.php/Bluetooth
-- David C. Rankin, J.D.,P.E.
This is good to know. However, the above webpaage recommends using the CLI method's bluetoothctl tool, which is apparently not provided by any of the packages installed on my system, and doing a YaST Software Manager -> Search for bluetoothctl with 'Description' and 'RPM-Provides' shows 'No results'. :-( -- To unsubscribe, e-mail: opensuse-kde3+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde3+owner@opensuse.org
On 2017-07-06 19:44:55 David C. Rankin wrote:
On 07/03/2017 08:24 PM, Leslie Turriff wrote:
When I try to configure Linux to communicate with my keyboard, using KInputWizard, it crashes as soon as I click on Add Device. Trace output from the KDE Crash Handler is as follows:
I would not use KInputWizard. The usb keyboard should not depend on KDE. Look at:
https://wiki.archlinux.org/index.php/Bluetooth
-- David C. Rankin, J.D.,P.E.
Hmmm... when I query YaST with 'File List' added, it says that bluetoothctl is provided by the bluez package, but when I run rpm -q bluez --filesbypkg | grep bin returns $ rpm -q bluez --filesbypkg | grep bin bluez /usr/bin/ciptool bluez /usr/bin/dfutool bluez /usr/bin/hcitool bluez /usr/bin/l2ping bluez /usr/bin/rfcomm bluez /usr/bin/sdptool bluez /usr/sbin/bccmd bluez /usr/sbin/bluetoothd bluez /usr/sbin/hciattach bluez /usr/sbin/hciconfig bluez /usr/sbin/hid2hci bluez /usr/sbin/rcbluetooth and rpm -q bluez --filesbypkg | grep bluetooth returns $ rpm -q bluez --filesbypkg | grep bluetooth bluez /etc/bluetooth bluez /etc/bluetooth/main.conf bluez /etc/bluetooth/rfcomm.conf bluez /etc/dbus-1/system.d/bluetooth.conf bluez /etc/default/bluetooth bluez /etc/init.d/bluetooth bluez /etc/init.d/bluetooth-coldplug bluez /etc/udev/rules.d/40-bluetooth.rules bluez /lib/udev/bluetooth.sh bluez /lib/udev/bluetooth_serial bluez /usr/lib64/bluetooth bluez /usr/lib64/bluetooth/plugins bluez /usr/lib64/bluetooth/plugins/audio.so bluez /usr/lib64/bluetooth/plugins/hal.so bluez /usr/lib64/bluetooth/plugins/input.so bluez /usr/lib64/bluetooth/plugins/network.so bluez /usr/lib64/bluetooth/plugins/serial.so bluez /usr/lib64/bluetooth/plugins/service.so bluez /usr/sbin/bluetoothd bluez /usr/sbin/rcbluetooth bluez /usr/share/man/man8/bluetoothd.8.gz bluez /var/adm/fillup-templates/sysconfig.bluetooth So where am I likely to find bluetoothctl? It looks to me like the tools the OpenSuSE packages are providing might be deprecated? The website says that hciconfig is. -- To unsubscribe, e-mail: opensuse-kde3+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde3+owner@opensuse.org
On 07/06/2017 10:07 PM, Leslie Turriff wrote:
So where am I likely to find bluetoothctl? It looks to me like the tools the OpenSuSE packages are providing might be deprecated? The website says that hciconfig is.
Yes, OpenSuSE is generally built on older stable versions, while Archlinux is build on the current upstream release version. (meaning if say bluez was version 5.44 and the maintainers release 5.45, then within usually 3 hours the packaged version on Arch is 5.45) On suse if Leap 42.2 was released with bluez 5.35, it stays 5.35 for the whole release cycle). My guess is you can do the same thing, you just have to use the man page or the documentation that came with 5.35 to do what the Arch wiki says bluetoothctl is now doing -- that's fairly common. I'm sure the 5.3X and 5.4X releases of bluez represent different milestones. Kinda like firefox 49 and firefox 52 do... Sorry I don't have any silver bullet for you on bluetooth (I rather avoid it like the plague...) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse-kde3+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde3+owner@opensuse.org
On 2017-07-07 08:54:38 David C. Rankin wrote:
Sorry I don't have any silver bullet for you on bluetooth (I rather avoid it like the plague...)
That's okay. This is my first experience with BlueTooth; it seems to be the only way to share a keyboard and mouse between two systems. I guess I expected that the support for such an "old" technology would be quite stable (silly me). One of the things that bugs me is the dearth of real documentation on these systems. (I have to admit that I've been totally spoiled by my thirty years in the mainframe environment, where the hardcopy documentation for just the components of the OS fills a moderately sized room, with separate volumes for installation, configuration, operation, tuning, and debugging; just the system messages and codes manual takes up four thick volumes.) I am continually confounded on one hand by sketchy man pages, and on the other by some that are so complex (e.g. sudo) as to be effectively useless, all couched in terminology seemingly intended to obscure rather than inform. This BlueTooth stuff is a case in point. How can someone attempting to configure a BlueTooth device be expected to know that the pertinent tool is called hciconfig? For that matter, looking at the tools provided by the bluez package, there is also one called hcitool. As usual, the man pages for these provide little in the way of helpful info. hcitool begins, NAME hcitool - configure Bluetooth connections SYNOPSIS hcitool [-h] hcitool [-i <hciX>] [command [command parameters]] DESCRIPTION hcitool is used to configure Bluetooth connections and send some spe- cial command to Bluetooth devices. If no command is given, or if the option -h is used, hcitool prints some usage information and exits. and hciconfig begins, NAME hciconfig - configure Bluetooth devices SYNOPSIS hciconfig -h hciconfig [-a] hciconfig [-a] [command [command parameters]] DESCRIPTION hciconfig is used to configure Bluetooth devices. hciX is the name of a Bluetooth device installed in the system. If hciX is not given, hci- config prints name and basic information about all the Bluetooth devices installed in the system. If hciX is given but no command is given, it prints basic information on device hciX only. Basic informa- tion is interface type, BD address, ACL MTU, SCO MTU, flags (up, init, running, raw, page scan enabled, inquiry scan enabled, inquiry, authen- tication enabled, encryption enabled). An example from the hciconfig man file "explaining" one of its parameters is voice [voice] With no voice, prints voice setting. Otherwise, sets voice set- ting to voice. voice is a 16-bit hex number describing the voice setting. There is no explanation of what voice does, and no description of the allowed values for this option or their meanings. This is typical of the content of most man files. It does look as if hciconfig might be more useful than hcitool; or perhaps there is a real distinction between 'devices' and 'connections'. Of course, these man pages don't describe how (or if) they complement one another. And there are a handful of other tools in the package that I'll have to examine. Of course, /usr/share/doc/packages/bluez is a waste of time; one wonders why anyone bothers with it... :-( On my ancient PPC Mac (which I keep solely to run an obsolete version of a package whose vendor is apparently afraid of Linux users), as soon as I powered it on, OS-X detected the presence of my new keyboard and ran a wizard to connect. I can understand that Linux doesn't install the software for a particular device if it is not present during installation, and I don't mind that it is configured via a CLI, but why does it have to be so obscurant? -- To unsubscribe, e-mail: opensuse-kde3+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde3+owner@opensuse.org
On 07/07/2017 10:54 PM, Leslie Turriff wrote:
That's okay. This is my first experience with BlueTooth; it seems to be the only way to share a keyboard and mouse between two systems. I guess I expected that the support for such an "old" technology would be quite stable (silly me). One of the things that bugs me is the dearth of real documentation on these systems. (I have to admit that I've been totally spoiled by my thirty years in the mainframe environment, where the hardcopy documentation for just the components of the OS fills a moderately sized room, with separate volumes for installation, configuration, operation, tuning, and debugging; just the system messages and codes manual takes up four thick volumes.) I am continually confounded on one hand by sketchy man pages, and on the other by some that are so complex (e.g. sudo) as to be effectively useless, all couched in terminology seemingly intended to obscure rather than inform.
Hah! When I started with NASA in 89 (I was an AE before an ATTY), we still used mainframes, BICs, etc. for flight design and to start and run both the fixed-base and motion-base simulators in Building 5. I'm not sure about spoiled. When they died, they died, and somebody way smarter on mainframes hand to breath life back into them :) (and the phone would start ringing off the hook if you kicked off an SVDS run before normal quitting time -- it would bring the whole system to a crawl. If I recall correctly it was about 750,000 lines of FORTRAN, common-blocks, yuk!)
This BlueTooth stuff is a case in point. How can someone attempting to configure a BlueTooth device be expected to know that the pertinent tool is called hciconfig? For that matter, looking at the tools provided by the bluez package, there is also one called hcitool. As usual, the man pages for these provide little in the way of helpful info.
Thank God the glic man pages are bullet-proof works of art. Now the individual packages like hcitool, etc. many times rely on just the package developer to put the pages together -- we all know how much priority documentation gets in our own projects. <snip>
An example from the hciconfig man file "explaining" one of its parameters is
voice [voice] With no voice, prints voice setting. Otherwise, sets voice set- ting to voice. voice is a 16-bit hex number describing the voice setting.
There is no explanation of what voice does, and no description of the allowed values for this option or their meanings. This is typical of the content of most man files.
I guess the developer expects us to reference the source-code for a complete understanding - even then, depending on comments in the code and his coding style, it can be a challenge.
It does look as if hciconfig might be more useful than hcitool; or perhaps there is a real distinction between 'devices' and 'connections'. Of course, these man pages don't describe how (or if) they complement one another. And there are a handful of other tools in the package that I'll have to examine. Of course, /usr/share/doc/packages/bluez is a waste of time; one wonders why anyone bothers with it... :-( On my ancient PPC Mac (which I keep solely to run an obsolete version of a package whose vendor is apparently afraid of Linux users), as soon as I powered it on, OS-X detected the presence of my new keyboard and ran a wizard to connect. I can understand that Linux doesn't install the software for a particular device if it is not present during installation, and I don't mind that it is configured via a CLI, but why does it have to be so obscurant?
The whole bluetooth thing is somewhat black box to me. I've never really used it other than on small devices that were intended for its use (e.g. wireless phone earbuds, etc.) Then the device handles the pairing process fairly easily. Here are a few more links that look relevant: https://unix.stackexchange.com/questions/96693/connect-to-a-bluetooth-device... https://wiki.debian.org/BluetoothUser https://help.ubuntu.com/stable/ubuntu-help/bluetooth-connect-device.html This reminds me of setting of a PXE-boot server. There was a 'smattering' of pages (some with old, some with new, some with bewildering) information. Think of yourself is a pioneer (or prospector) of bluetooth knowledge. Once you strike gold, you will be a prime candidate to update (or write) the suse bluetooth howto. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse-kde3+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde3+owner@opensuse.org
On 07/06/2017 10:07 PM, Leslie Turriff wrote:
So where am I likely to find bluetoothctl? It looks to me like the tools the OpenSuSE packages are providing might be deprecated? The website says that hciconfig is.
Yes,
OpenSuSE is generally built on older stable versions, while Archlinux is build on the current upstream release version. (meaning if say bluez was version 5.44 and the maintainers release 5.45, then within usually 3 hours the packaged version on Arch is 5.45) On suse if Leap 42.2 was released with bluez 5.35, it stays 5.35 for the whole release cycle). Turns out I had the KDE3 repository's priority set higher than the main repositories to avoid pulling down KDE4 or Plasma bits as much as possible, and the KDE3 repository has an old copy of the bluez package (heaven knows why; it's not part of KDE at all), hence, bluetoothctl was not installed. Adjusting the priority and reinstalling bluez fixed that up, at least. But
On 2017-07-07 08:54:38 David C. Rankin wrote: there seems to be no documentation at all for the current bluez package; no man page, no Documentation page on the website. :-( I followed the instructions on that ArchWiki page, but I'm stuck at the pair command, which supposedly should get a PIN request from the device, but in my case doesn't; after which the connect command fails. I'll have to dig around in the journals to see what's happening with this, but I thought you might be interested in my progress. :-) There seems to be no way to clear the partial configuration using bluetoothctl; at least its internal help feature doesn't show any. What fun. Leslie -- To unsubscribe, e-mail: opensuse-kde3+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde3+owner@opensuse.org
On 07/11/2017 03:30 AM, Leslie Turriff wrote:
I'll have to dig around in the journals to see what's happening with this, but I thought you might be interested in my progress. :-) There seems to be no way to clear the partial configuration using bluetoothctl; at least its internal help feature doesn't show any. What fun.
Good to hear. This is a prime example of why I no longer set repo priorities. (I used that trick in the past -- in the 10.X - 11.x days while setting /etc/zypp/zypp.con solver.allowVendorChange = true) Lately, I've found it much more advantageous to simply choose packages by passing the -r (--repo) flag to zypper to individually select any one (or set) of packages I want from an alternate vendor selection e.g. zypper in -r kde3 package [...] or using yast and selecting the repository I want files from. In both cases you are prompted to allow-vendor-change on a per-transaction basis rather than on a global basis. Have not had a single problem since 11.4 that way. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse-kde3+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde3+owner@opensuse.org
On 2017-07-13 03:23:11 David C. Rankin wrote:
Good to hear. This is a prime example of why I no longer set repo priorities. (I used that trick in the past -- in the 10.X - 11.x days while setting /etc/zypp/zypp.con solver.allowVendorChange = true)
Lately, I've found it much more advantageous to simply choose packages by passing the -r (--repo) flag to zypper to individually select any one (or set) of packages I want from an alternate vendor selection e.g.
zypper in -r kde3 package [...]
or using yast and selecting the repository I want files from.
In both cases you are prompted to allow-vendor-change on a per-transaction basis rather than on a global basis. Have not had a single problem since 11.4 that way.
Thanks for sharing this technique. I'll give it a try. -- To unsubscribe, e-mail: opensuse-kde3+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde3+owner@opensuse.org
participants (2)
-
David C. Rankin -
Leslie Turriff