Re: [g-a-devel]Re: Why Can't I use BRLTTY With Gnopernicus

"John J. Boyer" <director chpi org> writes:

> The thing that is causing me trouble is that keyboard emulation no longer
> works. It did right after you wrote ttybrl.c . I could
> pressd the down arrow key combination on my braille keyboard and Gnome 
> would do a down-arrow. If I was in a text box I could type a character on 
> the braille keyboard and it would appear on the screen. looking at the 
> source code for ttybrl.c I can see that it is trying to send keycodes that 
> have not been mapped somewhere. However, they are not getting a response. 
> My gues now is that something has changed in Gnome and the keycodes need 
> to be encoded differently. I have already informed Dave Mielke of this 
> problem.

Now I start to understand what you are refering too.  And you are
actually right, something changed with the way how BRLTTY behaves:

Keyboard emulation is implemented in BRLTTY directly by opening
the current virtual console, and inserting a certain keycombination. I
was actually very supprised to see that it worked in combination with
X, since the vc opened and inserted into is in that case the X console, and
not a standard text console.
At that time, libbrlapi was not forwarding keyboard emulation keypresses to
gnopernicus, rather brltty was just trying to do its magic, and succeeded.
Later on, we decided that BRLTTY should forward a lot more keypresses
to its clients, rather than trying to perform some obscure thing which
is by no means guaranteed to do the right thing.  Previsouly for instance,
BRLTTY was not forwaring keypresses like CR_DESCCHAR and friends to its clients,
which it could not provide any meaningful default behaviour for by itself

So, what you are seeing is that BRLTTY no longer tries to do keyboard emulation
on the X console directly, rather it sends a keypress to Gnopernicus.
However, Gnopernicus has no fascilities for keyboard emulation via
Braille input yet as far as I can see, so we can not really map those
keypresses to anything meaningful yet.

As a short-term solution, you could insert a call to brlapi_ignore into the
ttybrl.c initialisation function to tell brltty to no longer forward a certain
keycode-range to Gnopernicus.
This way, you would get the old behaviour.  Note however, that
this was IMHO really a feature by accident, it shouldn't be done the
way it worked.  For instance, since BRLTTY relies on its currently
defined translation table to figure out which braille key combinations
are which character, it would behave in a completely broken way whenever
Gnopernicus has a different translation table loaded than brltty has.
If you want to see proper Braille keyboard emulation, we will have
to work on getting this into Gnopernicus first.  I do know that the
BAUM Vario 80 has the equivalent of a Braille keyboard on it, but I am
not sure if this is implemented in the Gnopernicus driver yet.

> John
>  On Tue, 23 Sep 2003, Mario Lang wrote:
>> "John J. Boyer" <director chpi org> writes:
>> > So far it looks like brltty is the more likely, because everytime I press a
>> > key on my braille keyboard, except for a few, there is a message on the tty
>> > where I invoked startx that says "Default: sending DKxxxx".
>> This message is produced whenever the ttybrl module receives
>> a keycode which is not yet mapped to a corresponding Gnopernicus braille
>> keycode. Quoting brltty-3.3.1/Documentation/README.Gnopernicus, the
>> following table lists BRLTTY keypresses and their corresponding Gnopernicus 
>> actions.
>>    Command      Binding      Description
>>    ----------   -----------  -----------
>>    CMD_LNUP     DK00         Go To Parent
>>    CMD_HOME     DK01         Go To Focus
>>    CMD_LNDN     DK02         Go To Child
>>    CMD_FWINLT   DK03         Go To Previous
>>                 DK04         Repeat Last
>>    CMD_FWINRT   DK05         Go To Next
>>                 DK01DK02     Do Default Action
>>    CR_ROUTE     HMSnn        Route Cursor
>> Note that "Repeat Last" and "Do Default" are currently not mapped, because
>> we couldn't think of a really good keycode for them.
>> So, what should work for you is moving left/right and up/down in the
>> widget hierarchy.  Cursour routing keys, if you have some, should also work.
>> Everything else is just a question of filling out the case statement
>> in gnopernicu/braille/libbrl/ttybrl.c in function brltty_brl_glib_cb
>> to make the corresponding brltty keycodes to Gnopernicus braille keyboard codes.
>> However, note that this does not really prevent you from using Gnopernicus,
>> since all the navigation functions are mapped on the computer keypad anyway.
>> Note that the reason for the small number of mappings is mainly due to
>> the small number of default braille key to function bindings in Gnopernicus.
>> At the time I wrote ttybrl.c, the keycombinations listed above were the only
>> ones defined in Gnopernicus.  It would not have made much sense to
>> create more mappings, since they wouldn't have invoked anything anyway.
>> If Braille display support in Gnopernicus increases in flexibility,
>> it is very easy to add more mappings to ttybrl.c.
> -- 
> Computers to Help People, Inc.
> 825 East Johnson; Madison, WI 53703
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org

  Mario | Debian Developer <URL:>
        | Get my public key via finger mlang db debian org
        | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]