BTW, hcid.conf with his options where is documented?
Fredrik Noring wrote:
> Hi
>
> Attached patch makes it possible to use a configuration in hcid.conf
> for a device with a certain Bluetooth device address:
> options
> {
> # hcid options...
> }
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Nosve,
> BTW, hcid.conf with his options where is documented?
would you apply for the job of writing the hcid.conf manpage?
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Fredrik,
> The "char *ref" comment in hcid.h? I understand the kernel people you
> referred to before use this type of comment as well. :)
no, this comment is correct.
> The other three comments do not refer to the if:s but the code inside
> each if. So I don't think these are misplaced either.
/* First try to get BD_ADDR based settings ... */
di.dev_id = hdev;
if (!ioctl(sock, HCIGETDEVINFO, (void *) &di))
device_opts = get_bdaddr_device_opts(&di.bdaddr);
/* ... then try HCI based settings ... */
if (!device_opts)
device_opts = get_hci_device_opts(hdev);
/* ... and last use the default settings. */
if (!device_opts)
device_opts = &default_device;
Make it look like this. It is much more easier to read :)
> More places? That's the only comments I know of...
Not comments. Whitespaces and braces.
> > And of course in this case inlining the function is a good idea.
>
> Why is that?
Short code that only init a structure can be inlined.
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
l?r 2004-01-31 klockan 16.59 skrev Marcel Holtmann:
> I have seen more. Also misplaced comments ;)
The "char *ref" comment in hcid.h? I understand the kernel people you
referred to before use this type of comment as well. :)
The other three comments do not refer to the if:s but the code inside
each if. So I don't think these are misplaced either.
More places? That's the only comments I know of...
> This is too much and not needed, because we can use memset().
Sure.
> And of course in this case inlining the function is a good idea.
Why is that?
Fredrik
Hi Fredrik,
> As far as I can see there is only one misplaced space and two
> misplaced '{' characters in the entire patch, on lines 93, 312
> and 331 in main.c. :)
I have seen more. Also misplaced comments ;)
One other thing.
static void init_device_defaults(struct device_opts *device_opts)
{
device_opts->name = 0;
device_opts->class = 0;
device_opts->pkt_type = 0;
device_opts->scan = SCAN_PAGE | SCAN_INQUIRY;
device_opts->link_mode = 0;
device_opts->link_policy = 0;
device_opts->auth = 0;
device_opts->encrypt = 0;
}
This is too much and not needed, because we can use memset().
memset(device_opts, 0, sizeof(*device_opts));
device_opts->scan = SCAN_PAGE | SCAN_INQUIRY;
I know one function later it is used in the same style, but I don't like
it either. And of course in this case inlining the function is a good
idea.
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel
l?r 2004-01-31 klockan 16.30 skrev Marcel Holtmann:
> please also incorporate my coding style comments to this patch and
> resend it. I think this patch is very useful and I want to apply it.
As far as I can see there is only one misplaced space and two
misplaced '{' characters in the entire patch, on lines 93, 312
and 331 in main.c. :)
Fredrik
Hi Fredrik,
> > Attached patch implements both.
>
> The new version of the patch fixes a small memory leak.
please also incorporate my coding style comments to this patch and
resend it. I think this patch is very useful and I want to apply it.
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Achim,
tor 2004-01-29 klockan 00.16 skrev Achim Bohnet:
> I've a laptop with buildin bt and an external bt stick. It depends on the
> order I switch internal one on or connect the stick what interface is
> assigned to the same hardware. If there is a need (no idea yet I'm
> a bt newbie) for this feature selection by bdaddr is therefore useful
> to support. Selection by interface would be useless for me.
I think combining all three possibilities is the best:
device <bdaddr>
{
# This is the configuration for all
# devices that have matching bdaddr:s.
}
device <hci interface>
{
# This is the configuration for all devices
# that have matching interfaces but no matching
# bdaddr.
}
device
{
# This is the configuration for all devices
# that don't match anything else: the default.
}
This way one can mix and move devices around and hcid will do its
best to configure things properly.
Having a utility (e.g. config-bluetooth) managing all these
configurations simpifies things, of course.
> On the other hand if I ever take the another identical stick with me
> by accident, bdaddr would be different and the settings would not
> apply without a notice. Maybe a
>
> device default
> {
> complain loudly
> }
>
> is useful ;)
Well, simply having
device
{
# Default configuration.
}
already works today. :)
Fredrik
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Fredrik,
> Attached patch makes it possible to use a configuration in hcid.conf
> for a device with a certain Bluetooth device address:
>
> options
> {
> # hcid options...
> }
>
> device
> {
> # Default device options...
> }
>
> device 00:11:22:33:44:55
> {
> # Device options for bdaddr 00:11:22:33:44:55...
> }
>
> It's useful to do persistent device specific configurations, for example
> setting unique and meaningful names. I've only done limited testing.
I like the idea (also the second one with hci0). Please send me a patch
that enables both possibilities. But be aware of that I don't even had
reviewed your first one, so this can take some time before I will apply
it.
Has anyone already tested this patch? Do it break some other stuff?
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi
tor 2004-01-29 klockan 20.39 skrev Fredrik Noring:
> Attached patch implements both.
The new version of the patch fixes a small memory leak.
Fredrik
Marcel,
tor 2004-01-29 klockan 06.52 skrev Marcel Holtmann:
> I like the idea (also the second one with hci0). Please send me a patch
> that enables both possibilities.
Attached patch implements both.
Fredrik
On Wednesday 28 January 2004 20:24, Fredrik Noring wrote:
> ons 2004-01-28 klockan 19.56 skrev Fredrik Noring:
> > device 00:11:22:33:44:55
> > {
> > # Device options for bdaddr 00:11:22:33:44:55...
> > }
>
> Btw., a variation on the theme is to allow:
>
> device hci0
> {
> # Device options for interface hci0...
> }
>
> I don't know which one is most useful or if both should be allowed.
I've a laptop with buildin bt and an external bt stick. It depends on the
order I switch internal one on or connect the stick what interface is
assigned to the same hardware. If there is a need (no idea yet I'm
a bt newbie) for this feature selection by bdaddr is therefore useful
to support. Selection by interface would be useless for me.
On the other hand if I ever take the another identical stick with me
by accident, bdaddr would be different and the settings would not
apply without a notice. Maybe a
device default
{
complain loudly
}
is useful ;)
Achim
>
> Fredrik
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
>
>
--
To me vi is Zen. To use vi is to practice zen. Every command is
a koan. Profound to the user, unintelligible to the uninitiated.
You discover truth everytime you use it.
-- [email protected]
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
ons 2004-01-28 klockan 19.56 skrev Fredrik Noring:
> device 00:11:22:33:44:55
> {
> # Device options for bdaddr 00:11:22:33:44:55...
> }
Btw., a variation on the theme is to allow:
device hci0
{
# Device options for interface hci0...
}
I don't know which one is most useful or if both should be allowed.
Fredrik
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi
Attached is a new hcid man page update. Except for default device
paramater inheritance and the device specific "autoinit" paramater,
it should be accurate but somewhat incomplete for hcid-2.4-fn8 at:
http://noring.nocrew.org/bluetooth/
Next I plan to implement persistent DBus device configuration
management. This will make hcid and the Gnome Bluetooth Configuration
tool ready, feature wise, for an initial release, I think.
I suspect Marcel has more comments on the extended interfaces etc. so
these will probably be adjusted in the future.
Fredrik
Hi Nosve and Marcel
Attached is a draft for a hcid.1 man page.
The hcid.conf format is slightly changed to make it more useful
and flexible but these changes are not implemented in hcid yet.
Please comment.
Fredrik
Hi Nosve,
> Sure, why not! I have to start from parser.c ?
the config file format is defined by parser.y and lexer.l
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
>>Hi Nosve,
>>
>>> BTW, hcid.conf with his options where is documented?=
>>
>>would you apply for the job of writing the hcid.conf manpage?
>>=
>>Regards
>>
>>Marcel
>>
>>
>>
Sure, why not! I have to start f=
rom parser.c ?