Hello,
I was wondering why there is a CreateDevice in org.bluez.input.Manager
if CreateSecureDevice will fall back to the same behavior if the
device in question does not support secure pairing.
bluez-gnome switched to CreateSecureDevice after that method was added
which broke users who still had older bluez-utils (no changes to
require a newer bluez-utils were made). Would it not have been better
to just add the security routines to the existing CreateDevice? Is it
too late to change this now?
Best Regards,
Andrew Jorgensen
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Andrew,
>>> Aren't you maintaining bluez-gnome? Could you add this fallback to
>>> properties/input.c?
>>
>> feel free to send a patch :)
>
> Trouble is that it doesn't return anything, it just segfaults.
> Probably it's being called in some wrong way. I might look at it
> someday but given that I can just remove 'Secure' if bluez-utils is
> too old I think I'll just leave the package patched.
if it segfaults then it is a bug in bluez-gnome. It should never
segfault only because a method is not available.
>>> I'm curious what you mean by "would have broken the API." Do you
>>> mean
>>> if we were to remove the method now after it has been released?
>>> If so
>>> then I agree, it's too late.
>>
>> We can't add any parameters to an already established method call.
>> And
>> there are cases were we wanna use a device in an unpaired way.
>
> There can be an input device that can be used in either paired or
> unpaired mode as desired? I wouldn't have thought any such thing
> existed, but if that's so then I agree and am sorry to have troubled
> you about it.
The HID specification and its implementation are broken in some cases :(
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Thu, Mar 6, 2008 at 3:56 AM, Marcel Holtmann
> > Aren't you maintaining bluez-gnome? Could you add this fallback to
> > properties/input.c?
>
> feel free to send a patch :)
Trouble is that it doesn't return anything, it just segfaults.
Probably it's being called in some wrong way. I might look at it
someday but given that I can just remove 'Secure' if bluez-utils is
too old I think I'll just leave the package patched.
> > I'm curious what you mean by "would have broken the API." Do you mean
> > if we were to remove the method now after it has been released? If so
> > then I agree, it's too late.
>
> We can't add any parameters to an already established method call. And
> there are cases were we wanna use a device in an unpaired way.
There can be an input device that can be used in either paired or
unpaired mode as desired? I wouldn't have thought any such thing
existed, but if that's so then I agree and am sorry to have troubled
you about it.
Thanks,
Andrew
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Andrew,
> Aren't you maintaining bluez-gnome? Could you add this fallback to
> properties/input.c?
feel free to send a patch :)
> I'm curious what you mean by "would have broken the API." Do you mean
> if we were to remove the method now after it has been released? If so
> then I agree, it's too late.
We can't add any parameters to an already established method call. And
there are cases were we wanna use a device in an unpaired way.
> But I'm curious why a new method was added rather than new
> functionality to the existing method. Are there new callbacks that
> would have broken existing clients? I guess it's a moot point now
> though.
See my point above. It is not that simple.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Tue, Mar 4, 2008 at 3:25 PM, Marcel Holtmann
> yes, it is too later and it would have broken the API. If
> CreateSecureDevice returns with no such method error, you can always
> fallback to CreateDevice.
Hi Marcel,
Aren't you maintaining bluez-gnome? Could you add this fallback to
properties/input.c?
I'm curious what you mean by "would have broken the API." Do you mean
if we were to remove the method now after it has been released? If so
then I agree, it's too late.
But I'm curious why a new method was added rather than new
functionality to the existing method. Are there new callbacks that
would have broken existing clients? I guess it's a moot point now
though.
Thanks,
Andrew
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Andrew,
> I was wondering why there is a CreateDevice in org.bluez.input.Manager
> if CreateSecureDevice will fall back to the same behavior if the
> device in question does not support secure pairing.
>
> bluez-gnome switched to CreateSecureDevice after that method was added
> which broke users who still had older bluez-utils (no changes to
> require a newer bluez-utils were made). Would it not have been better
> to just add the security routines to the existing CreateDevice? Is it
> too late to change this now?
yes, it is too later and it would have broken the API. If
CreateSecureDevice returns with no such method error, you can always
fallback to CreateDevice.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel