is more than one HCI node present
- Use errx(3) instead of err(3) if there is no HCI node present as errno
is 0 in this case and the resulting error message wouldn't make much sense
Approved by: emax (mentor)
parameter optional.
- Add Read_Node_List command which prints a list of available HCI nodes,
their Netgraph IDs and connected hooks
Reviewed by: emax
Approved by: emax
MFC after: 1 week
register, remove or change services in the local database. For now only
accept the request if the peer has effective user ID the same as 'root'
user ID.
MFC after: 1 week
connections to Bluetooth HID device. As soon as Bluetooth HID device
is powered off (or goes out of RF range) the stack will terminate both
connections. File descriptors for both connections will become active
on next select(2) call. Because bthidd(8) processes file descriptors
in order, it will detect descriptor for one of the closed connections
first and kill the session. However, there is still a second (active)
descriptor that used to point to the same session. bthidd(8) used to
assert() if it cant find session by file descriptor, which was wrong.
While I'm here fix a couple of typos in parser.y
Reported by: Eric Anderson anderson AT centtech DOT com
MFC after: 3 days
That should fix the problem with invalid PSM returned from bthidcontrol.
Pointy hat goes to me.
PR: misc/76107
Submitted by: Hiroyuki Aizu < aizu at navi dot org >
MFC after: 1 day
instead of BD_ADDRs
- Convert BD_ADDRs in l2ping(8) output into the human readable names via
bt_gethostbyaddr(3)
- Introduce and document '-n' - numberic output option
Suggested by: Anil Madhavapeddy <anil at recoil dot org>
disappearing from the tree. We already were splitting the baby (using
the symbol for the vendor BROADCOM, but not for the device). Use
#defines for both.
Note: bthidd(8) is still not complete. Need to commit kernel
support (a-la Linux /dev/input) to feed HID events into kernel.
Also need to write bthidd(8) and bthidd.conf(5) man pages.
that this provokes. "Wherever possible" means "In the kernel OR NOT
C++" (implying C).
There are places where (void *) pointers are not valid, such as for
function pointers, but in the special case of (void *)0, agreement
settles on it being OK.
Most of the fixes were NULL where an integer zero was needed; many
of the fixes were NULL where ascii <nul> ('\0') was needed, and a
few were just "other".
Tested on: i386 sparc64
