|
This is NOT problem / does not requires code / details and answer.
Basic statement
"bluez" (library) is part of the Linux kernel.
Academic question:
what is the basic / fundamental access of Bluetooth to Linux kernel ?
Is bypassing "bluez / hci " the way ?
"bluez" library uses "hci" "commands" , other GUI applications / commands are "free to utilize bluez" ....
For example - Qt uses "bluez" but have no means to actually reset Bluetooth devices - it will access devices no longer near system....
so do other application(s) .
|
|
|
|
|
Salvatore Terress wrote: "bluez" (library) is part of the Linux kernel.
Well part of it is, which provides the actual kernel interface and drivers. The other part is the user space components which provide for the developer access. More details can be found at BlueZ » About[^]. You cannot bypass the library, since user space code cannot use Kernel features directly.
|
|
|
|
|
I have "upgraded" to Ubuntu 23.04.
"Discovered"it is lacking Bluetooth.
Used this opportunity to test "verify Bluetooth " in my code using "bluetoothctl".
The command responds correctly , but "gets stuck "
in "Waiting to connect to bluetoothd...".
Used same command in "terminal" with same result.
Can somebody suggest similar command or "bluetoothctl"command option (timeout ?)so it does detect lack of Bluetooth, but does not get stuck.
Temporary , I do verify Bluetooth not working by looking for "Agent registered " failure - which is correct response when Bluetooth is OK, actually running. Then if it runs I can "exit" from command.
Help is much appreciated.
Thanks
nov25-1@nov251-desktop:~$ bluetoothctl
Waiting to connect to bluetoothd...
|
|
|
|
|
|
I certainly cannot find a way to change a timeout for it.
Presumably this is your actual situation since it was not clear whether you fixed the first.
1. Bluetooth is not installed
2. You ran the command.
3. It blocks.
Given that then in terms of error detection for a tool you would need to do the following
1. Code something that can run the command asynchronously such as a thread.
2. The caller initiates the call with a timer (that will expire.)
3. If the timer fires a timeout then the tool reports 'bluetooth not found'
4. If the command returns (before the timeout) cancel the timer, then process the results from the command.
|
|
|
|
|
Sorry for delay, had to move my PC and it all broke. Appreciate both suggestions, will use both. While testing, found out that some commands requires "boot access" on "check if enabled" and no "root access" "enable service" -- weird and incontinent.
|
|
|
|
|
Found bluetoothctl --timeout BUT it is not working as expected.
Any idea ?
( Maybe it is not going to work when no bluettoth is NOT running ?)
nov25-1@nov251-desktop:~$ bluetoothctl --timeout
bluetoothctl: option '--timeout' requires an argument
bluetoothctl ver 5.66
Usage:
bluetoothctl [--options] [commands]
Options:
--agent Register agent handler: <capability>
--endpoints Register Media endpoints
--monitor Enable monitor output
--timeout Timeout in seconds for non-interactive mode
--version Display version
--help Display help
nov25-1@nov251-desktop:~$ bluetoothctl --timeout 20
Waiting to connect to bluetoothd...
|
|
|
|
|
That's pretty clear. You need to tell bluetoothctl how long to wait e.g. bluetoothctl --timeout 2 should time out after 2 seconds. Who knows, maybe you could even use a floating point value e.g. --timeout 1.5 for finer grain control.
Normally, though, a long option is specified as --timeout=2, so you might try that as well if the above does not work. I've checked a few of web sites, but none of them were able to help in this regard. Still a little experimentation on your part should clear that up. When you get it sorted, maybe post a note the to the maintainers that it needs to be explained better.
Keep Calm and Carry On
|
|
|
|
|
Message Closed
Kidding, I just wanted in on the fun.
Jeremy Falcon
|
|
|
|
|
Right.
So you're suggesting I knock my core count down to below 8, say 7 ..., reboot then fire up that linux programmer's 64-bit windows app which can't see any architecture above 2 gigastories and try rendering at level four and everything will turn out all right? 
|
|
|
|
|
The message was closed (and I don't know why), and I don't recall what it said.
However, your tone suggests something I'm not too keen in entertaining.
Jeremy Falcon
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
I googled the following. It appears to return answers.
C system stdin
|
|
|
|
|
Message Closed
modified 4-May-23 8:37am.
|
|
|
|
|
Member 14968771 wrote: The -S (stdin) option causes sudo to read the password from the standard input instead of the terminal device.
Which is what my post it about.
You run the command in code.
Then you code that code so you can control "standard input" (ie "stdin") which is exactly what I suggested via my google search.
By steps.
1. Write code to run the command
2. Figure out how to use the 'stdin' input in the code. That allows your code to pass content to the 'stdin' of the command.
3. You then pass input in via that code to the command.
|
|
|
|
|
It would be much easier to call sudo from the terminal before you try to run whatever code itb is that you are trying to run that requires privileged access. My limited testing does not seem to allow this to be run from inside a program.
|
|
|
|
|
An easier option might be to configure sudo to allow the user of your program to call it without a password. The sudoers file is the place to do this. Obviously there may be security implications with this, but that is up to you to decide.
Another alternative is to set the set-user-id bit on your executable so that it automatically runs as root (using chmod and chown). Again, this has security implications to think about.
|
|
|
|
|
Rather than system() take a look at popen() popen(3): pipe stream to/from process - Linux man page
But before you do that, you should stop and think about whatever it is you think you need to sudo. As a general rule user level programs should not need to elevate privilege to perform work. That's a security hole waiting to be exploited. If you need to create a device file, load a kernel module or change permissions on a device file, that should be handled by the OS at boot time or device initialization time (eg a USB device being plugged in). Using sudo is almost certainly the Wrong Thing, and should only be considered when all other options have been exhausted.
Keep Calm and Carry On
|
|
|
|
|
Message Closed
modified 4-May-23 8:39am.
|
|
|
|
|
The expression "echo ""q"" | sudo ... " doesn't do what I think you think it does. But it all works out anyway. This time. Successive string constants, with only intervening white space get concatenated together so
printf("Hello"
" World!\n");prints Hello World!. See. You learned something from "sidechatter"!
Member 14968771 wrote: I need to be honest - I am getting discouraged by posters "making small talk" posts such as
...make sure you have a backup...
...it is a security issue...
To my mind, there's been very little in your previous posts that suggest you have any idea what issues you might be unleashing with your blind man with a sledgehammer approach. There's no sense that you understand what the possible consequences of your choices are. Given that, it would be remiss of us not to point out the possible pitfalls of your "solutions" ... many of which, I at least, find dubious. And most of us have "Been there, done that" in terms of making unwise or uninformed choices, and had to rebuild, repair, and recover. If we're lucky, damage to customer systems, and our reputations, has been minimal. But we learn. We grow. We pass on our insights (and war stories) to others in hopes that they will learn, remember and be proactive in areas like security before it affects them or their customer's in negative ways. It's all about an ounce of prevention being worth a pound of cure. If we can guide others away from dangers, I think we should, rather then letting the foolhardy walk unprepared into the lions den.
For example, I don't think that creating /dev/rfcomm0 as a soft link to /dev/ttyUSB0 is going to achieve what you expect. Have you tested this approach and got the results you want? Looking at this post https://unix.stackexchange.com/a/410128 regarding a missing /dev/rfcomm0, it seems highly unlikely that creating a link between what seems to be a USB serial device and what I can only assume is supposed to be a bluetooth device binding is going to work. They're completely different objects. It seems like you're trying to create a link between, say /dev/sda and /dev/console, and expect GPU I/O operations to somehow be magically interpreted to save video to the disk.
But maybe you have already done some testing and know that works. I don't know. I can only wish you luck.
Keep Calm and Carry On
|
|
|
|
|
Member 14968771 wrote: I am trying to resolve an issues , not to having to listen to such well meaning but in my view superficial commentaries...
Then pay someone for the answer maybe?
Forums, free forums, depend on posters posting whatever they want.
|
|
|
|
|
Member 14968771 wrote: I am getting discouraged by posters "making small talk"
And we are largely doing this because, as usual, it is far from clear what actual problem you are trying to solve. The original question is fine as it stands, but with more detail we may be able to offer alternative answers. There may be a perfectly reasonable answer to your real problem, but we cannot giuess what that is. You really need to stop attacking everyone for not providing what you determine is the right answer, and stop and think about the quality of the questions you post here.
|
|
|
|
|
The quality of the answers you get is directly dictated by the quality of the questions you ask.
|
|
|
|
|
Member 14968771 wrote: therefore I am removing it.
It was bad idea to delete the original question. 
Now no one reading this discussion won't understand its subject... 
|
|
|
|
|
You need to understand that he really doesn't care for advice.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
