Wednesday, April 30, 2014
Posted by urnenfeld a las 21:45
Friday, April 18, 2014
The system was going unconditionally to sleep after 3 minutes after the power on, and afterwards sleeping each 30 seconds.
Google did not show anyone with this situation therefore here is the post for the next one. As not being a Linux expert I was out of clue who is triggering the action.
Hint: as in the base installation there are not so many processes so a top commands shows some useful information. Certainly yes, each time the suspend happened a new process looked get the CPU. Anyway the time between top acknowledging the process and showing it, and the system suspending was in the order of milliseconds my eyes could not see it.
Hint2: Waste cpu in a paralel process so that my eyes, or a camera could see it:
This would work for a single core CPU, the next item would be setting top to update as fast as possible, and the third recording it with your smartphone video camera.
The process to blame was systemd-logind. It is a service inside systemd which can be configured in /etc/systemd/logind.conf check here for details.
Somehow some of the suspend/hibernate buttons of the laptop were detected as pressed. Where the system(Compaq Evo laptop) had no such keys. Therefore I recommend to look at which keys you really want to have functional and ignore the rest:
Wednesday, July 11, 2012
So here is a piece of overview documentation of all I have been doing these years(dia format):
L2cap under network/protocols/l2cap: Provides socket interface to have l2cap channels. L2CAP offers connection oriented and connectionless sockets. But bluetooth stack as this point has no interchangeability with TCP/IP, A Higher level Bluetooth profile must be implemented
HCI under src/add-ons/kernel/bluetooth : Here we have 2 modules, one for handling global bluetooth data structures such as connection handles and L2cap channels, and frames
H2generic under src/add-ons/kernel/drivers/
Bluetooth kit under src/kit/bluetoothC++ implementation based on JSR82 api
bluetoothThe USB driver, implementing the H2 transport
Bluetooth Server under src/servers/bluetoothBasically handling opened devices (local connected fisically in our system) and forwaring kit calls to them
Bluetooth Preferences under src/preferences/bluetooth
Configuration using the kit
Test applications under src/tests/kits/bluetooth
Thank you all
Saturday, August 28, 2010
Related my development I did a small incrusion in Caya development, implementing some features I needed to feel comfortable regarding the chat windows behaviour. BTW last release with MSN support!
But focusing on bluetooth L2CAP and its sockets interface has been a bit improved. As we said in the previous post, Haiku could initiate a pairing process and establish a communication link.
The next step was to allow Haiku act as a client to request opening a channel in the given communication link to finally interchange real user information from node to node.
There has been implemented a test application in src/test/kits/bluetooth/l2capClient. I was able to request pairing with a device (a Motorola V5), open a communication channel and send dummy data to him. the phone obviously did not understand information, and closed the communication.
Still unmature and some configuration parameters are unsupported, but if both nodes are Haiku, they could send information that each other understand. Therefore with that implemented some small applications could be implemented to have 2 haiku nodes interchanging normal user data wireless through bluetooth. This opens possibilities to implement small custom and non standard applications to:
- Chat between 2 nodes.
- Send flattened BMessages
- File exchanges
Sunday, June 27, 2010
A bit of status update,
During the last months I have been working stabilizing the HCI layer, and the user interaction to pair. Up to now I was using the remote device to be the master of the communication therefore using that incoming information to guide the implementation.
Haiku could before search for remote devices, but could not decide by itself to communicate with them. Then a "Pair" button has been implemented in preferences. Implementing encrypted and non encrypted pairing with them. Additionally there is a new checkbox in preferences(with an unfortunate location at the moment) to indicate that Haiku requires, that link to be placed between devices, to be encrypted:
This is maybe the most complex messages interchange in HCI layer together with scanning devices. There was then work rewriting and refactoring code in the server to be able to see clearly how sequences flowed.
Here we can see how Haiku forces my phone to match a pincode, hardly readeable as usual, but it says in Spanish "haiku-bluetooth, Add to My Devices?"
Next step is make the same at L2cap layer. Haiku more or less handles l2cap channels as slave, so now it is turn to act as master too...
Posted by urnenfeld a las 10:25
Saturday, May 29, 2010
There was a bug I carried since long ago, It was hard to detect and its reproduction was depending very much on how well the Slab allocator worked for net_buffers. The debugging shown like trying to send a buffer that was already sent... all fake as it was a reused one.
There were important internal features to be implemented as to have a dedicated thread to handle all incomming RX data, before it was done almost all in interrupt context, therefore the USB or transport bus usage is more responsible now.
Posted by urnenfeld a las 22:01