Re: [BRLTTY] Handytech Active Braille

[Mario Lang]

Vincent LE GOFF  writes:

> I'm currently testing a Handytech Active Braille display and I'm now
> trying to use BRLTTY with it.  Strangely enough, BRLTTY recognizes the
> display at once and with no particular problem,

Good.

> but key mappings don't work at all as expected.  The scrolling buttons
> (up and down) behaves like arrow keys (moving the cursor instead of
> the Braille window).

Only the left rocker behaves like cursor up/down.
The right rocker moves the display up/down.

>   The Braille keys do some additional strange things, but they don't
> write as far as I can tell.

The dot keys are configured to do navigation functions by default.  If
you want to use them to type Braille, you can enable that with
Dot7+Dot8+RightSpace.  To go back to the navigation mode, press 
Dot7+Dot8+LeftSpace.

>   Since I was using BRLTTY 5.3, I tried to get the most recent release
> and run from it.   After some problems (not completely fixed yet) I've
> got a working BRLTTY 5.5 to find out the same problem persisted.

We have been using these key bindings since a very long time now :-)

> Does anyonw own such a display and know if there is a specific set of
> action to use a proper key mapping with BRLTTY?

What do you consider proper?

>   Is it somehow a mistake in the original driver, and if so, can it be
> fixed?

It is not a bug.

-- 
CYa,
  ⡍⠁⠗⠊⠕ | Blog:   GitHub: 
  .''`. | Twitter: @blindbird23FaceBook: disyled
 : :' : | SoundCloud: 
 `. `'  | YouTube: 
   `-
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.com
For general information, go to: http://brltty.com/mailman/listinfo/brltty

Re: [BRLTTY] Music notation .bse???

[Mario Lang]

Dave Mielke  writes:

> [quoted lines by Adrian van Bloois on 2017/11/17 at 22:48 +0100]
>
> You see a lot of Dot7s (which should be ignored or removed) because
> strict BRF is being used.

This is why we have the -6 option of brltty-trtxt.
I usually clean up BRF Braille music by converting to Unicode Braille
and adding -6 to brltty-trtxt.

-- 
CYa,
  ⡍⠁⠗⠊⠕ | Blog:   GitHub: 
  .''`. | Twitter: @blindbird23FaceBook: disyled
 : :' : | SoundCloud: 
 `. `'  | YouTube: 
   `-
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.com
For general information, go to: http://brltty.com/mailman/listinfo/brltty

Re: [BRLTTY] BrlAPI Raw key code mode?

[Mario Lang]

Dave Mielke <d...@mielke.cc> writes:

> [quoted lines by Mario Lang on 2017/07/28 at 10:14 +0200]
>
>>At least what I am seeing is, that no commands whatsoever arrive if I have 
>>selected "raw keycode" mode. Which makes sense, since you probably wouldn't 
>>be 
>>able to differentiate commands and raw keycodes returned from brlapi__readKey 
>>anyway?
>
> [...] Some drivers do still send some commands directly.  Touch commands
> might be done that way (I don't recall at the moment).

Yes, I don't get any TOUCH events via raw keycode mode right now.
This would be a nice to have.  As I understand it, we'd need to create a
Key group
(HT_GRP_Touch) and map the touch positions to key numbers, translating
thatlater on to TOUCH commands via the key table mechanism.  Does this sound 
right?

-- 
CYa,
  ⡍⠁⠗⠊⠕ | Blog: <https://blind.guru/>  GitHub: <https://github.com/mlang/>
  .''`. | Twitter: @blindbird23FaceBook: disyled
 : :' : | SoundCloud: 
 `. `'  | YouTube: 
   `-
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.com
For general information, go to: http://brltty.com/mailman/listinfo/brltty

Re: [BRLTTY] BrlAPI Raw key code mode?

[Mario Lang]

Dave Mielke <d...@mielke.cc> writes:

> [quoted lines by Mario Lang on 2017/07/28 at 09:03 +0200]
>
>>I would even go as far as dropping the exception for BRL_SWITCHVT and 
>>similar.  
>>After all, the client has just requested raw keycodes, they should know what 
>>they are doing in that particular situation.
>
> Is raw mode a special kind of key, i.e. does it share the value space for the 
> rest of what can be returned?

I am not sure, but I am guessing no.  At least what I am seeing is, that
no commands whatsoever arrive if I have selected "raw keycode"
mode. Which makes sense, since you probably wouldn't be able to
differentiate commands and raw keycodes returned from brlapi__readKey
anyway?

> If it occupies its own value space then I'd argue that the command
> exception list is, in fact, entirely an error in raw mode.

-- 
CYa,
  ⡍⠁⠗⠊⠕ | Blog: <https://blind.guru/>  GitHub: <https://github.com/mlang/>
  .''`. | Twitter: @blindbird23FaceBook: disyled
 : :' : | SoundCloud: 
 `. `'  | YouTube: 
   `-
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.com
For general information, go to: http://brltty.com/mailman/listinfo/brltty

Re: [BRLTTY] BrlAPI Raw key code mode?

[Mario Lang]

Dave Mielke <d...@mielke.cc> writes:

> [quoted lines by Mario Lang on 2017/07/27 at 21:17 +0200]
>
>>This did the trick:
>>
>>  brlapi_range_t Ranges[1];
>>  Ranges[0].first = 0;
>>  Ranges[0].last = 0X;
>>  brlapi__acceptKeyRanges(BrlAPI->handle(), Ranges, 1);
>
> Here's what I think is a btter way to code the initialization:
>
>brlapi_range_t ranges[] = {
>  { .first = 0, .last = UINT64_MAX }
>};

In C, yes.  C++ does not support the .field syntax.
But UINT64_MAX is a good hint, although C++ also does that a bit
differently (std::numeric_limits::max()).
Quite a mouthful, but more flexible and less error prone.

The way I code it now is:

  brlapi_range_t Ranges[] = {
{ std::numeric_limits::min()
, std::numeric_limits::max()
}
  };
  brlapi__acceptKeyRanges(
BrlAPI->handle(),
Ranges, std::distance(std::begin(Ranges), std::end(Ranges))
  );

"Look ma, no magic numbers and no macros either!" :-)
But I'd prefer to not do this at all (see below)

>>Either the documentation or the code needs to be fixed.
>>I would vote for making the code do what the documentation claims.
>
> So do I. Having to accept specific ranges makes no sense (to me) in raw mode.

I agree.  I would even go as far as dropping the exception
for BRL_SWITCHVT and similar.  After all, the client has just
requested raw keycodes, they should know what they are doing in that
particular situation.

-- 
CYa,
  ⡍⠁⠗⠊⠕ | Blog: <https://blind.guru/>  GitHub: <https://github.com/mlang/>
  .''`. | Twitter: @blindbird23FaceBook: disyled
 : :' : | SoundCloud: 
 `. `'  | YouTube: 
   `-
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.com
For general information, go to: http://brltty.com/mailman/listinfo/brltty

Re: [BRLTTY] BrlAPI Raw key code mode?

[Mario Lang]

Shérab <sebastien.hinde...@ens-lyon.org> writes:

> Mario Lang (2017/07/27 16:40 +0200):
>> In fact, I know the core doesn't pass the keypresses on because some of
>> the keys result in BRLTTY playing a sound, as if it were trying to read
>> a screen.  Maybe the detection logic for brl_keyToCommand() is the
>> problem?  Or something else?
>
> See the brlapi_acceptKeyRange function & co. You may need to let BrlAPI
> know which keys your application is interested in. I thought in "raw
> keycode" mode all the keys would be passed to the client by defautl but
> it may not be the case.

The documentation of "Raw keycode" mode does explicitly state that
brlapi_acceptKeyRange() is not necessary.  I will give it a try.
What should I pass?

-- 
CYa,
  ⡍⠁⠗⠊⠕ | Blog: <https://blind.guru/>  GitHub: <https://github.com/mlang/>
  .''`. | Twitter: @blindbird23FaceBook: disyled
 : :' : | SoundCloud: 
 `. `'  | YouTube: 
   `-
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.com
For general information, go to: http://brltty.com/mailman/listinfo/brltty

Re: [BRLTTY] BrlAPI Raw key code mode?

[Mario Lang]

Dave Mielke  writes:

>>Actually, it seems the HandyTech driver does not support delivering raw
>>key codes yet. It should define the BRL_HAVE_KEY_CODES macro and
>>implement the brl_readKey and brl_keyToCommand methods.
>
> That made sense way back in the days when bindings were hard-coded, but I 
> don't 
> think it's the right way to do it now. My personal opinion is that raw key 
> codes should be the values defined within the key tables. That way, no driver 
> would require any extra support for it.

I totally agree.  As already said in another reply in this thread, being
able to grab keyEvents via BrlAPI would be useful and revive the
current keycode feature, which seems sort of bitrotten to the point of
almost being unusable.

Is there anything that I (with my limited understanding of the core) can
do to help in this?

-- 
CYa,
  ⡍⠁⠗⠊⠕ | Blog:   GitHub: 
  .''`. | Twitter: @blindbird23FaceBook: disyled
 : :' : | SoundCloud: 
 `. `'  | YouTube: 
   `-
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.com
For general information, go to: http://brltty.com/mailman/listinfo/brltty

Re: [BRLTTY] BrlAPI Raw key code mode?

[Mario Lang]

Shérab <sebastien.hinde...@ens-lyon.org> writes:

> Mario Lang (2017/07/23 11:54 +0200):
>> Oh!!!  Thanks for reminding me.  Indeed, now it dawns on me that there
>> is this driver-specific translation mechanism...  This sort of got lost
>> in the noise (for me) since we have introducted key tables.  I guess I
>> need to see if the HandyTech driver can be extended with these
>> translation functions.
>
> Yes. I expect this to be not too hard because the code that converts
> keycodes to commands is already there somehow, more or less explicitly.
> So, in my experience, such a change mostly consists in factorizing the
> driver code and making it cleaner.

Grepping for brl_keyToCommand and brl_readKey, I only find the Visio and
TTY drivers to have such a function.  Seems my original feeling is true, though 
for
different reasons: raw keycode mode isn't supported by a majority of the
drivers.  So it isn't really about just HandyTech, rather, the question
seems to be: do we still care for this feature?  If so, should we make
an effort to convert our drivers to support it?  Or is there a better
way, now that we have key name tables?

>>   if (Number == -1) throw std::system_error(brlapi_errno, 
>> std::generic_category());
>>   return { this, Number };
>> }
>
> With this code, will you get proper BrlAPI error messages?

std::error_code, which is what is being used under the hood here, allows
to pass low level error codes around.  And yes, indeed, this *will*
allow for proper BrlAPI error messages.  For now, I am just pretending
brlapi_errno contains standard errno values.  Once I get to it, it is
just a matter of implementing a BrlAPI::ErrorCategory and using it inside
of the throw instead of generic_category, and the exception message will
automatically contain the proper error message, and can also still be
handled programatically.

> In other words, does your code call brlapi_strerror or the like
> somewhere?

Not yet, but everything in place to do that soon.

> Just to be sure. Assuming the current code is made to work correctly,
> why wouldn't you be able to implement your tool with the code in its
> present state? Why do you need symbolic key names for that?

I would be able to do what I want with raw keycodes as well.  But not
needing to duplicate keycode decoding logic for every supported model in
the client would be convenient.  Symbolic was probably misleading.
While a function to retrieve the actual key name from the driver would
probably be a nice to have, what I am actually thinking about is an
interface to how most drivers tell the core that a key was pressed or
released these days.  Take the following example statement from the
HandyTech driver as an example:

return enqueueKeyEvent(brl, HT_GRP_RoutingKeys, byte - HT_KEY_ROUTING, 
!release);

There is a key group, an actual key value, and the press/release status.
As the example nicely shows, the decoding of keycodes basically
happens before enqueueKeyEvent is finally called.  It are these, still
untranslated to commands, but already logically decoded key events that
I am interested in as a BrlAPI client.  If backwards compatibility is an
issue, just go for a new name like brlapi__readKeyEvent.  But since we
have the information on that level inside of the core since the key name
table rewrite, I think we should make it possible for BrlAPI clients to
make use of it.  Since all drivers that have been rewritten to use key
tables should actually call enqueueKeyEvent at some point, passing key
events to BrlAPI clients should also not need any driver change.
Contrary to enabling old keycode mode, which I don't really know how to
fit into the new callback way.

-- 
CYa,
  ⡍⠁⠗⠊⠕ | Blog: <https://blind.guru/>  GitHub: <https://github.com/mlang/>
  .''`. | Twitter: @blindbird23FaceBook: disyled
 : :' : | SoundCloud: 
 `. `'  | YouTube: 
   `-
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.com
For general information, go to: http://brltty.com/mailman/listinfo/brltty

Re: [BRLTTY] BrlAPI Raw key code mode?

[Mario Lang]

Shérab <sebastien.hinde...@ens-lyon.org> writes:

> Mario Lang (2017/07/23 00:12 +0200):
>> Hi.
>> 
>> Does anyone know if Raw keycode mode of BrlAPI does still work?  Here,
>> calling brlapi__readKey after brlapi__enterTtyMode with "HandyTech" as
>> the driver string seems to block forever, while "" as driver string
>> gives me command keys as expected.
>
> Did it work in the past or is that your first attempt with this driver?

If it ever worked for me, it was a long time ago.

>> I know the number of users of raw
>> mode might be near to nothing, so I am sort of guessing it might have
>> been broken somewhere in the past?
>
> Actually, it seems the HandyTech driver does not support delivering raw
> key codes yet. It should define the BRL_HAVE_KEY_CODES macro and
> implement the brl_readKey and brl_keyToCommand methods.

Oh!!!  Thanks for reminding me.  Indeed, now it dawns on me that there
is this driver-specific translation mechanism...  This sort of got lost
in the noise (for me) since we have introducted key tables.  I guess I
need to see if the HandyTech driver can be extended with these
translation functions.

> What I find strange, though, is that you do not get a proper error from
> BrlAPI. Normally, if you try to enter in raw keycode mode with a driver
> that does not support it, you should get an oeration not supported
> error, I think.

I just checked, and no, I didn't miss error handling:

BrlAPI::TTY BrlAPI::Connection::tty(int TTY, bool Raw) {
  auto Number = brlapi__enterTtyMode(BrlAPI->handle(), TTY, Raw? "HandyTech" : 
"");
  if (Number == -1) throw std::system_error(brlapi_errno, 
std::generic_category());
  return { this, Number };
}

It reports an error (no device or address) if I pass an invalid driver
name string.  Maybe it should report a similar error if the driver
string is correct, but the driver doesn't have the translation functions?

>> Also, now that we have symbolic key names, I wonder, is there any
>> possibility to create some sort of "hybrid" raw mode for BrlAPI, which
>> would return key names and press/release status?
>
> Samuel and I should probably think about it, indeed.

Please do.  I have an actual use case herre, which I'd like to implement
in the upcoming months.  I'd like to build a musical instrument (a
control voltage sequencer) out of a Braille display as main (and only) 
interface.  For
that, having to deal with BRLTTY commands is not very convenient since
what I am building is not a screen reader, rather, it is a native
braille based hardware/software sequencer.  Here is a repository
already, but it only contains binding code for now.  Maybe another
result of this will be modern C++ BrlAPI bindings:
https://github.com/mlang/brlcv

-- 
CYa,
  ⡍⠁⠗⠊⠕ | Blog: <https://blind.guru/>  GitHub: <https://github.com/mlang/>
  .''`. | Twitter: @blindbird23FaceBook: disyled
 : :' : | SoundCloud: 
 `. `'  | YouTube: 
   `-
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.com
For general information, go to: http://brltty.com/mailman/listinfo/brltty

[BRLTTY] BrlAPI Raw key code mode?

[Mario Lang]

Hi.

Does anyone know if Raw keycode mode of BrlAPI does still work?  Here,
calling brlapi__readKey after brlapi__enterTtyMode with "HandyTech" as
the driver string seems to block forever, while "" as driver string
gives me command keys as expected.  I know the number of users of raw
mode might be near to nothing, so I am sort of guessing it might have
been broken somewhere in the past?  Or am I just confused?

Also, now that we have symbolic key names, I wonder, is there any
possibility to create some sort of "hybrid" raw mode for BrlAPI, which
would return key names and press/release status?

-- 
CYa,
  ⡍⠁⠗⠊⠕ | Blog:   GitHub: 
  .''`. | Twitter: @blindbird23FaceBook: disyled
 : :' : | SoundCloud: 
 `. `'  | YouTube: 
   `-
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.com
For general information, go to: http://brltty.com/mailman/listinfo/brltty

Re: [BRLTTY] adding custom command to replace a braille window

[Mario Lang]

Vikash Kesharwani  writes:

> Translation is not an issue. I am facing issue with cursor routing. It does
> not work all the time. Can there be any particular reason for this. Is
> cursor routing guaranteed to execute( I am using nano) or there is any
> scenario in which it can fail.
>
> I can see message that cursor is moving from [row1,colo1] -> [row2,col2]
> but it does not go to [row2,colo2] but stops before that.

Most editors do not allow you to move the cursor to the right of
inserted text/spaces.  Could that be the problem you are seeing?
IOW, if you are on a blank line, and invoke cursor routing
to go to the right of the current position, it will fail because the
editor does not allow arrow movements in that direction.  In general, if
you can go there by just using cursor keys, cursor routing should lso be
able to go there.  If you can not reach the location with normal cursor
keys, cursor routing will also not be able to go there.

One exception of this is picture-mode in Emacs.  But I guess most people
don't even know about that, so it is not really relevant here.

-- 
CYa,
  ⡍⠁⠗⠊⠕ | Blog:   GitHub: 
  .''`. | Twitter: @blindbird23FaceBook: disyled
 : :' : | SoundCloud: 
 `. `'  | YouTube: 
   `-
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.com
For general information, go to: http://brltty.com/mailman/listinfo/brltty

Re: [BRLTTY] The launch of my crowd funding campaign on Patreon.

[Mario Lang]

Luke Yelavich  writes:

> I am writing to let you all know of my newly launched crowd funding campaign 
> to continue to work full time on Linux accessibility development. Please 
> spread the word if you are able, it would be much appreciated.
>
> https://patreon.com/lukefoss

This page is totally inaccessible with Lynx.
Since I was not able to read a synopsis of your campaign, what is it
exactly that you are offering to work on full-time?
Did Ubuntu stop to support you?  If so, why?

-- 
CYa,
  ⡍⠁⠗⠊⠕ | Blog:   GitHub: 
  .''`. | Twitter: @blindbird23FaceBook: disyled
 : :' : | SoundCloud: 
 `. `'  | YouTube: 
   `-
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.com
For general information, go to: http://brltty.com/mailman/listinfo/brltty

Re: [BRLTTY] 5.5 will be released soon.

[Mario Lang]

Dave Mielke  writes:

>>and are there some non translated strings in this future release?
>
> Mario should now be able to give you a good answer to this question since 
> he's 
> updated the German translations.

The messages template is up-to-date.  Please change to the Messages
subdirectory, run "make fr.po", fix translations marked as fuzzy, and
send the resulting file.  There hasn't been much activity since the
start of 5.4, but a few changes have happened.

-- 
CYa,
  ⡍⠁⠗⠊⠕
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.com
For general information, go to: http://brltty.com/mailman/listinfo/brltty

Re: [BRLTTY] Testing on Windows

[Mario Lang]

Samuel Thibault  writes:

> The source seems to be downloadable on
>
> https://3rdpartysource.microsoft.com/download/Redistributed%20OSS/5.4/brltty-5.4.zip
>
> It seems to correspond to git 8d46edbf16 + a cherry-pick of 738c1d8b76
> (which was submitted by microsoft at the time).

There is one change I could isolate which was apparently never
submitted.
Note, that they (Marko?) have only done this to libusb.inf, not libusb-1.0.inf.

Samuel, can you tell if this would be a useful change to adopt?

--- a/Autostart/Windows/brltty-libusb.inf
+++ b/Autostart/Windows/brltty-libusb.inf
@@ -46,7 +46,7 @@ libusb_files_dll_x64 = 10,system32
 libusb0.sys
 
 [libusb_files_sys_x64]
-libusb0.sys,libusb0_x64.sys
+libusb0_x64.sys
 
 [libusb_files_dll]
 libusb0.dll
@@ -55,7 +55,7 @@ libusb0.dll
 libusb0.dll
 
 [libusb_files_dll_x64]
-libusb0.dll,libusb0_x64.dll
+libusb0_x64.dll
 
 ;--
 ; Device driver
@@ -87,7 +87,7 @@ AddReg = libusb_add_reg_hw
 AddService = libusb0, 0x0002, libusb_add_service
 
 [LIBUSB_DEV.NTAMD64.Services]
-AddService = libusb0, 0x0002, libusb_add_service
+AddService = libusb0, 0x0002, libusb_add_service_amd64
 
 [libusb_add_reg]
 HKR,,DevLoader,,*ntkern
@@ -114,6 +114,14 @@ StartType  = 3
 ErrorControl   = 0
 ServiceBinary  = %12%\libusb0.sys
 
+[libusb_add_service_amd64]
+DisplayName= "LibUsb-Win32 - Kernel Driver 03/31/2007, 0.1.12.1"
+ServiceType= 1
+StartType  = 3
+ErrorControl   = 0
+ServiceBinary  = %12%\libusb0_x64.sys
+
+
 ;--
 ; Devices
 ;--

-- 
CYa,
  ⡍⠁⠗⠊⠕ | Blog:   GitHub: 
  .''`. | Twitter: @blindbird23FaceBook: disyled
 : :' : | SoundCloud: 
 `. `'  | YouTube: 
   `-
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.com
For general information, go to: http://brltty.com/mailman/listinfo/brltty

Re: [BRLTTY] Testing on Windows

[Mario Lang]

Felix Grützmacher - Help Tech Elektronik GmbH
<felix.gruetzmac...@handytech.de> writes:

> short version: it works for me!

Good to know!

> We'll find out what they're doing and let you know.

Thanks.

I hear the Narrator add-on identifies itself as 5.4M.  That raises a few
questions.  If anyone can figure out the URL of the actual
download, that would be highly appreciated for analysis.

> -Ursprüngliche Nachricht-
> Von: BRLTTY [mailto:brltty-boun...@brltty.com] Im Auftrag von Mario Lang
> Gesendet: Donnerstag, 6. April 2017 11:30
> An: 'Informal discussion between users and developers of BRLTTY.'
> Betreff: Re: [BRLTTY] Testing on Windows
>
> Felix Gr tzmacher - Help Tech Elektronik GmbH 
> <felix.gruetzmac...@handytech.de> writes:
>
>> I just tested Easy Braille (ID 0x44) with the following result:
>> 2017-04-06@10:17:55.937 USB: testing device: vendor=1FE4 product=0044
>> 2017-04-06@10:17:55.937 USB: setup packet: Typ:80 Req:06 Val:0300 
>> Idx: Len:00FF
>> 2017-04-06@10:17:55.937 USB: control input: 04 03 09 04
>> 2017-04-06@10:17:55.937 USB: USB language: 409
>> 2017-04-06@10:17:55.937 USB: setup packet: Typ:80 Req:06 Val:0301 
>> Idx:0409 Len:00FF
>> 2017-04-06@10:17:55.937 USB: control input: 36 03 48 00 61 00 6E 00 64 
>> 00 79 00 20 00 54 00 65 00 63 00 68 00 20 00 45 00 6C 00 65 00 6B 00 
>> 74 00 72 00 6F 00 6E 00 69 00 6B 00 20 00 47 00 6D 00 62 00 48 00
>> 2017-04-06@10:17:55.937 USB: Manufacturer Name: Handy Tech Elektronik 
>> GmbH
>> 2017-04-06@10:17:55.937 USB: setup packet: Typ:80 Req:06 Val:0302 
>> Idx:0409 Len:00FF
>> 2017-04-06@10:17:55.937 USB: control input: 1A 03 45 00 61 00 73 00 79 
>> 00 20 00 42 00 72 00 61 00 69 00 6C 00 6C 00 65 00
>> 2017-04-06@10:17:55.937 USB: Product Description: Easy Braille
>> 2017-04-06@10:17:55.937 USB: setting configuration: 1
>> 2017-04-06@10:17:55.937 USB: setup packet: Typ:80 Req:06 Val:0200 
>> Idx: Len:00FF
>> 2017-04-06@10:17:55.947 USB: control input: 09 02 29 00 01 01 00 80 32 
>> 09 04 00 00 02 03 00 00 00 09 21 10 01 00 01 22 46 20 07 05 81 03 3C 
>> 00 0A 07 05 02 03 3C 00 0A
>> 2017-04-06@10:17:55.947 USB: claiming interface: 0
>> 2017-04-06@10:17:55.947 program exit event added: 
>> sorted-usb-serial-adapters
>> 2017-04-06@10:17:55.947 USB: setup packet: Typ:81 Req:06 Val:2200 
>> Idx: Len:0720
>> 2017-04-06@10:17:55.947 USB: control input: 06 A0 FF 09 01 A1 01 09 01 
>> 15 00 25 FF 75 08 95 3C 81 00 09 02 15 00 25 FF 75 08 95 3C 91 00 C0
>> 2017-04-06@10:17:55.947 HID report not found: 01
>> 2017-04-06@10:17:55.947 USB: releasing interface: 0
>> 2017-04-06@10:17:55.947 braille driver initialization failed: ht -> USB:
>>
>> So this failed but for seemingly different reasons.
>> Hope this helps, and if there's any other way I can assist, please let me 
>> know.
>
> I am confused, esp. since I just learnt that I know someone who is 
> successfully running an AB4 with BRLTTY and Narrator (one of your resellers, 
> actually, I guess you know whom I'm talking about).
>
> So while the error above is another riddle, I too now think that you are 
> testing with a device which is different from what we originally had to 
> implement support for.  Or your libusb is corrupting packets.  Or
> something similarily strange.   To repeat, I know an AB4 user who is
> successfully using it on Windows with the BRLTTY version that is being 
> offered by Microsoft for download.  So, back to the drawing table:
> It would be very nice to know if your AB4 works on Linux.
>
> --
> CYa,
>   ? | Blog: <https://blind.guru/>  GitHub: <https://github.com/mlang/>
>   .''`. | Twitter: @blindbird23FaceBook: disyled
>  : :' : | SoundCloud:   `. `'  | YouTube: 
> 
>`-
> ___
> This message was sent via the BRLTTY mailing list.
> To post a message, send an e-mail to: BRLTTY@brltty.com For general 
> information, go to: http://brltty.com/mailman/listinfo/brltty
>
> ___
> This message was sent via the BRLTTY mailing list.
> To post a message, send an e-mail to: BRLTTY@brltty.com
> For general information, go to: http://brltty.com/mailman/listinfo/brltty

-- 
CYa,
  ⡍⠁⠗⠊⠕ | Blog: <https://blind.guru/>  GitHub: <https://github.com/mlang/>
  .''`. | Twitter: @blindbird23FaceBook: disyled
 : :' : | SoundCloud: 
 `. `'  | YouTube: 
   `-
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.com
For general information, go to: http://brltty.com/mailman/listinfo/brltty

Re: [BRLTTY] Testing on Windows

[Mario Lang]

Felix Grützmacher - Help Tech Elektronik GmbH
 writes:

> I just tested Easy Braille (ID 0x44) with the following result:
> 2017-04-06@10:17:55.937 USB: testing device: vendor=1FE4 product=0044
> 2017-04-06@10:17:55.937 USB: setup packet: Typ:80 Req:06 Val:0300 Idx: 
> Len:00FF
> 2017-04-06@10:17:55.937 USB: control input: 04 03 09 04
> 2017-04-06@10:17:55.937 USB: USB language: 409
> 2017-04-06@10:17:55.937 USB: setup packet: Typ:80 Req:06 Val:0301 Idx:0409 
> Len:00FF
> 2017-04-06@10:17:55.937 USB: control input: 36 03 48 00 61 00 6E 00 64 00 79 
> 00 20 00 54 00 65 00 63 00 68 00 20 00 45 00 6C 00 65 00 6B 00 74 00 72 00 6F 
> 00 6E 00 69 00 6B 00 20 00 47 00 6D 00 62 00 48 00
> 2017-04-06@10:17:55.937 USB: Manufacturer Name: Handy Tech Elektronik GmbH
> 2017-04-06@10:17:55.937 USB: setup packet: Typ:80 Req:06 Val:0302 Idx:0409 
> Len:00FF
> 2017-04-06@10:17:55.937 USB: control input: 1A 03 45 00 61 00 73 00 79 00 20 
> 00 42 00 72 00 61 00 69 00 6C 00 6C 00 65 00
> 2017-04-06@10:17:55.937 USB: Product Description: Easy Braille
> 2017-04-06@10:17:55.937 USB: setting configuration: 1
> 2017-04-06@10:17:55.937 USB: setup packet: Typ:80 Req:06 Val:0200 Idx: 
> Len:00FF
> 2017-04-06@10:17:55.947 USB: control input: 09 02 29 00 01 01 00 80 32 09 04 
> 00 00 02 03 00 00 00 09 21 10 01 00 01 22 46 20 07 05 81 03 3C 00 0A 07 05 02 
> 03 3C 00 0A
> 2017-04-06@10:17:55.947 USB: claiming interface: 0
> 2017-04-06@10:17:55.947 program exit event added: sorted-usb-serial-adapters
> 2017-04-06@10:17:55.947 USB: setup packet: Typ:81 Req:06 Val:2200 Idx: 
> Len:0720
> 2017-04-06@10:17:55.947 USB: control input: 06 A0 FF 09 01 A1 01 09 01 15 00 
> 25 FF 75 08 95 3C 81 00 09 02 15 00 25 FF 75 08 95 3C 91 00 C0
> 2017-04-06@10:17:55.947 HID report not found: 01
> 2017-04-06@10:17:55.947 USB: releasing interface: 0
> 2017-04-06@10:17:55.947 braille driver initialization failed: ht -> USB:
>
> So this failed but for seemingly different reasons.
> Hope this helps, and if there's any other way I can assist, please let me 
> know.

I am confused, esp. since I just learnt that I know someone who is
successfully running an AB4 with BRLTTY and Narrator (one of your
resellers, actually, I guess you know whom I'm talking about).

So while the error above is another riddle, I too now think that you are
testing with a device which is different from what we originally had to
implement support for.  Or your libusb is corrupting packets.  Or
something similarily strange.   To repeat, I know an AB4 user who is
successfully using it on Windows with the BRLTTY version that is being
offered by Microsoft for download.  So, back to the drawing table:
It would be very nice to know if your AB4 works on Linux.

-- 
CYa,
  ⡍⠁⠗⠊⠕ | Blog:   GitHub: 
  .''`. | Twitter: @blindbird23FaceBook: disyled
 : :' : | SoundCloud: 
 `. `'  | YouTube: 
   `-
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.com
For general information, go to: http://brltty.com/mailman/listinfo/brltty

Re: [BRLTTY] Testing on Windows

[Mario Lang]

Felix Grützmacher - Handy Tech Elektronik GmbH
 writes:

> Here is a log excerpt created from running as debug. Seems something went
> wrong.

Basically the exact same log was already submitted by you in July 2016.
Dave analyzed it quite in detail in 
<20160712095617.gp26...@beta.private.mielke.cc>.

Reading the thread from back then (which unfortunately didn't come to a
conclusion), I have the feeling the bug is in libusb-1.0, or at least,
in how we use it.  Having written the support for AB4, I definitely know
it worked on Linux, I just don't have any right now to test it.
However, I know my AS4 is working on Linux via USB.

> 2017-04-05@09:05:11.514 usbSubmitRequest error 40: Function not implemented.

I don't particularily remember ever having seen this message on Linux.
While I understand from reading the reply linked above that this is
just a warning, I still wonder if this might be the crucial difference.
AIUI, Dave is saying this warning would force the core to communicate
differently with the device, maybe something it doesn't do on Linux?

We basically have two different types of Handy Tech USB HID
implementations in the driver.
The first generation (usbOperations2) was when the Easy Braille was released.
In that version, we are reading/writing from/to the device via
HID reports (usbHidGetReport()/usbHidSetReport()).  Later
on, somehwere around the Active Braille, this didn't work anymore.
We had to change to reading/writing HID frames from/to the USB endpoint 
directly.
Without ever having tried so, I have a feeling maybe these two different
implementations aren't really necessary, and we should be able to
implement AB with the HID report layer as well.  For that train of
thought it would be interesting to know if the
Braille Star HID or Easy Braille do work with BRLTTY on Windows.
As I suspect you might have some around, Felix, could you please check
if usbOperations2 devices do work on Windows (USB Product ID 0X0044 or 0X0074).

And as you probably know a lot about the firmware, maybe you have an
idea what the difference between an Easy Braille and an Active
Braille USB interface is, and why we had to adapt the code when the
Active Braille was released.  It clearly worked on Linux, but strictly
speaking, if I remember correctly, we were really just guessing back
then, and what we guessed happend to work on Linux.
After all of these years, I am still far from being an expert in the
lower-level details of USB, however, I can't get rid of the feeling that
the way how usbOperations3 is implemented feels a bit like a hybrid.

Just some stabs into the dark, trying to dig up driver dev history to
maybe find a way to adapt our code without needing to hope/wait for a
libusb fix.

-- 
CYa,
  ⡍⠁⠗⠊⠕
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.com
For general information, go to: http://brltty.com/mailman/listinfo/brltty

Re: [BRLTTY] Testing on Windows

[Mario Lang]

Felix Grützmacher - Help Tech Elektronik GmbH
 writes:

> yes, this is an actual physical Active Braille it's talking to, with
> standard firmware.

I might be lying, but I believe Felix is the first person to test AB/AS
models on Windows.  At least I never did, and I don't remember any AB/AS
uwsers on Windows.  So this might as well be a platform specific problem.

-- 
CYa,
  ⡍⠁⠗⠊⠕
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.com
For general information, go to: http://brltty.com/mailman/listinfo/brltty

Re: [BRLTTY] braille star 40

[Mario Lang]

Felix Grützmacher - Handy Tech Elektronik GmbH
 writes:

> this might just be me stating the really obvious and making a fool of
> myself, but since the FTDI chip emulates a serial connection through USB and
> the FTDI driver takes care of that, wouldn't it make sense for the device to
> appear as serial rather than USB?

From the point of view of BRLTTY, an operating system provided serial
port is a nice fallback, but not the default.  BRLTTY actually natively
talks to the various USB chips without needing the OS to provide a
serial port.  However, that said, I am suspecting there might be
problems with this on Mac.  Anyway, as long as Cheryl refuses to look at
the logs, there is no way to know exactly.

> At least on Windows when I connect this kind of device I get a COM
> port, and my Braille driver doesn't see this as USB at all.

Yes, this is how it also was on Linux many years ago.  However, we
didn't want to rely on the kernel supporting a particular chip.

-- 
CYa,
  ⡍⠁⠗⠊⠕ | Blog:   GitHub: 
  .''`. | Twitter: @blindbird23FaceBook: disyled
 : :' : | SoundCloud: 
 `. `'  | YouTube: 
   `-
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.com
For general information, go to: http://brltty.com/mailman/listinfo/brltty