Heya,
As seen in https://bugzilla.redhat.com/show_bug.cgi?id=450081
The Microsoft Wireless Notebook Presenter Mouse 8000 has its name in
ISO-8859-1 instead of UTF-8, as required by the BT spec.
I've implemented a small work-around. This isn't very invasive, IMO, as
we already do UTF-8 checks.
In my tests, this makes the mouse show up as:
Microsoft? Wireless Notebook Presenter Mouse 8000
Cheers
Hi Bastien,
>>>> As seen in https://bugzilla.redhat.com/show_bug.cgi?id=450081
>>>> The Microsoft Wireless Notebook Presenter Mouse 8000 has its name
>>>> in
>>>> ISO-8859-1 instead of UTF-8, as required by the BT spec.
>>>>
>>>> I've implemented a small work-around. This isn't very invasive,
>>>> IMO, as
>>>> we already do UTF-8 checks.
>>>>
>>>> In my tests, this makes the mouse show up as:
>>>> Microsoft? Wireless Notebook Presenter Mouse 8000
>>>
>>> Attached is patch in the proper format.
>>
>> I see the need for this one, but just a failing UTF-8 check to
>> assume we
>> are using ISO-8859-1 is not good enough. Since the mouse has a DID
>> record, can we tie this together with the VID and PID?
>
> In those kind of cases, we can only guess what the encoding would
> be, we
> can't detect those encodings reliably. Given that we fallback to the
> old
> behaviour when the device, and that ISO-8859-X corresponds 1-1 with
> UTF-8 for the ASCII characters, I don't think it's such a stretch to
> think that American companies (who'd be using ISO-8859-1) would be the
> worst offenders for this sort of mistake.
>
> I don't think special casing only this device would be a good idea.
> As I
> mentioned, I reproduced the bug by making my computer, running BlueZ,
> adopt that name.
can we just fallback to ASCII only? Looks better to me than assuming
Latin-1. We replace invalid characters with spaces in that case.
Regards
Marcel
On Sat, 2009-03-14 at 07:21 +0100, Marcel Holtmann wrote:
> Hi Bastien,
>
>
> > > As seen in https://bugzilla.redhat.com/show_bug.cgi?id=450081
> > > The Microsoft Wireless Notebook Presenter Mouse 8000 has its name in
> > > ISO-8859-1 instead of UTF-8, as required by the BT spec.
> > >
> > > I've implemented a small work-around. This isn't very invasive, IMO, as
> > > we already do UTF-8 checks.
> > >
> > > In my tests, this makes the mouse show up as:
> > > Microsoft? Wireless Notebook Presenter Mouse 8000
> >
> > Attached is patch in the proper format.
>
> I see the need for this one, but just a failing UTF-8 check to assume we
> are using ISO-8859-1 is not good enough. Since the mouse has a DID
> record, can we tie this together with the VID and PID?
In those kind of cases, we can only guess what the encoding would be, we
can't detect those encodings reliably. Given that we fallback to the old
behaviour when the device, and that ISO-8859-X corresponds 1-1 with
UTF-8 for the ASCII characters, I don't think it's such a stretch to
think that American companies (who'd be using ISO-8859-1) would be the
worst offenders for this sort of mistake.
I don't think special casing only this device would be a good idea. As I
mentioned, I reproduced the bug by making my computer, running BlueZ,
adopt that name.
Hi Bastien,
> > As seen in https://bugzilla.redhat.com/show_bug.cgi?id=450081
> > The Microsoft Wireless Notebook Presenter Mouse 8000 has its name in
> > ISO-8859-1 instead of UTF-8, as required by the BT spec.
> >
> > I've implemented a small work-around. This isn't very invasive, IMO, as
> > we already do UTF-8 checks.
> >
> > In my tests, this makes the mouse show up as:
> > Microsoft® Wireless Notebook Presenter Mouse 8000
>
> Attached is patch in the proper format.
I see the need for this one, but just a failing UTF-8 check to assume we
are using ISO-8859-1 is not good enough. Since the mouse has a DID
record, can we tie this together with the VID and PID?
Regards
Marcel
On Thu, 2009-03-05 at 18:48 +0000, Bastien Nocera wrote:
> Heya,
>
> As seen in https://bugzilla.redhat.com/show_bug.cgi?id=450081
> The Microsoft Wireless Notebook Presenter Mouse 8000 has its name in
> ISO-8859-1 instead of UTF-8, as required by the BT spec.
>
> I've implemented a small work-around. This isn't very invasive, IMO, as
> we already do UTF-8 checks.
>
> In my tests, this makes the mouse show up as:
> Microsoft? Wireless Notebook Presenter Mouse 8000
Attached is patch in the proper format.
Cheers
Hi Bastien,
On Thu, May 05, 2011, Bastien Nocera wrote:
> > Patch to do that attached.
>
> And one that compiles (sigh).
> From 2b4524b060d980a7899c03359cd4943c9ad9cfe4 Mon Sep 17 00:00:00 2001
> From: Bastien Nocera <[email protected]>
> Date: Mon, 8 Nov 2010 16:43:42 +0000
> Subject: [PATCH] Handle non-UTF-8 device names
>
> http://thread.gmane.org/gmane.linux.bluez.kernel/1687
> https://bugzilla.redhat.com/show_bug.cgi?id=450081
> ---
> src/event.c | 19 ++++++++++++-------
> 1 files changed, 12 insertions(+), 7 deletions(-)
Pushed upstream. Thanks.
Johan
On Thu, 2011-05-05 at 19:02 +0100, Bastien Nocera wrote:
> On Mon, 2009-03-23 at 16:45 +0100, Marcel Holtmann wrote:
> > Hi Bastien,
> >
> > >>>> As seen in https://bugzilla.redhat.com/show_bug.cgi?id=450081
> > >>>> The Microsoft Wireless Notebook Presenter Mouse 8000 has its name
> > >>>> in
> > >>>> ISO-8859-1 instead of UTF-8, as required by the BT spec.
> > >>>>
> > >>>> I've implemented a small work-around. This isn't very invasive,
> > >>>> IMO, as
> > >>>> we already do UTF-8 checks.
> > >>>>
> > >>>> In my tests, this makes the mouse show up as:
> > >>>> Microsoft? Wireless Notebook Presenter Mouse 8000
> > >>>
> > >>> Attached is patch in the proper format.
> > >>
> > >> I see the need for this one, but just a failing UTF-8 check to
> > >> assume we
> > >> are using ISO-8859-1 is not good enough. Since the mouse has a DID
> > >> record, can we tie this together with the VID and PID?
> > >
> > > In those kind of cases, we can only guess what the encoding would
> > > be, we
> > > can't detect those encodings reliably. Given that we fallback to the
> > > old
> > > behaviour when the device, and that ISO-8859-X corresponds 1-1 with
> > > UTF-8 for the ASCII characters, I don't think it's such a stretch to
> > > think that American companies (who'd be using ISO-8859-1) would be the
> > > worst offenders for this sort of mistake.
> > >
> > > I don't think special casing only this device would be a good idea.
> > > As I
> > > mentioned, I reproduced the bug by making my computer, running BlueZ,
> > > adopt that name.
> >
> > can we just fallback to ASCII only? Looks better to me than assuming
> > Latin-1. We replace invalid characters with spaces in that case.
>
> Patch to do that attached.
And one that compiles (sigh).
On Mon, 2009-03-23 at 16:45 +0100, Marcel Holtmann wrote:
> Hi Bastien,
>
> >>>> As seen in https://bugzilla.redhat.com/show_bug.cgi?id=450081
> >>>> The Microsoft Wireless Notebook Presenter Mouse 8000 has its name
> >>>> in
> >>>> ISO-8859-1 instead of UTF-8, as required by the BT spec.
> >>>>
> >>>> I've implemented a small work-around. This isn't very invasive,
> >>>> IMO, as
> >>>> we already do UTF-8 checks.
> >>>>
> >>>> In my tests, this makes the mouse show up as:
> >>>> Microsoft? Wireless Notebook Presenter Mouse 8000
> >>>
> >>> Attached is patch in the proper format.
> >>
> >> I see the need for this one, but just a failing UTF-8 check to
> >> assume we
> >> are using ISO-8859-1 is not good enough. Since the mouse has a DID
> >> record, can we tie this together with the VID and PID?
> >
> > In those kind of cases, we can only guess what the encoding would
> > be, we
> > can't detect those encodings reliably. Given that we fallback to the
> > old
> > behaviour when the device, and that ISO-8859-X corresponds 1-1 with
> > UTF-8 for the ASCII characters, I don't think it's such a stretch to
> > think that American companies (who'd be using ISO-8859-1) would be the
> > worst offenders for this sort of mistake.
> >
> > I don't think special casing only this device would be a good idea.
> > As I
> > mentioned, I reproduced the bug by making my computer, running BlueZ,
> > adopt that name.
>
> can we just fallback to ASCII only? Looks better to me than assuming
> Latin-1. We replace invalid characters with spaces in that case.
Patch to do that attached.
Cheers