[BRLTTY] BrlAPI and contiguous displays

[Mario Lang]

Hi.

I've seriously started to use Orca with a Modular Evolution 88.
Currently, the "status cells" (the display is contiguous, i.e. there
is no break between the 80 cells and the remaining 8 cells) can not
be used by Orca.  This is
 1. slightly confusing since the BRLTTY status cell info is still shown while
    Orca (or some other screen reader) is using the display.
 2. Wasteful.  Especially in graphical environments, the screen width
    is no longer a fixed number.  To waste 8 cells is really a loss for the
    user.  Actually, considering the price of this device,
    not to use 8 cells means to waste 1400 EUR.

I am aware that the status cell issue is a problem in general from
the API POV.  However, I still want to propose a solution
for contiguous display models: Drivers which support
contiguous displays like the Evolution (or the Satellite 70 for instance) would
set a contiguous type variable in the BrailleDsiplay structure
upon brl_open().  The value of that variable could be something like:

typedef enum {
  NOT_CONTIGUOUS = 0,
  STATUS_CELLS_LEFT,
  STATUS_CELLS_RIGHT
} ContiguousCells;

If an API client requests brlapi_displaySize for
a display with a non-zero contiguous setting, the api_server adds up the
textCell and statusCell count and reports them all together to the client.
When a write request is received, the API server distributes the write onto
the text and status cells of the contiguous display according to the
contiguous setting (write to status cells first or last).

Rationale: Providing full status cell support to API clients is
difficult because the layout of separate status cells on various
models is very different from each other.  Therefore it is
not really easy to generalize for API clients without having to put
alot of detail into such an API.  However, contiguous displays
represent an exception as they actually
don't have any real status cells.  BRLTTY just claims (for
the benefit of a fixed-screen width console) that the display has
separate status cells.  I propose that BrlAPI should
overwrite that internal decision when exporting information
about contiguous displays to API clients.

Problems: Currently, drivers map directly statuscell routing key
presses to some global commands like HELP.  For full compatibility,
we'd need to pass a command like CMD_ROUTESTATUS to the core so that
api_server can correctly remap routing key presses for contiguous displays.

This change should not involve an API changes since it
would only affect internal behaviour of api_server.c.  I have a hope that
if we agree on this, that we can do it before 3.8.

-- 
CYa,
  Mario | Debian Developer <URL:http://debian.org/>
  .''`. | Get my public key via finger mlang at db.debian.org
 : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
 `. `'
   `-      <URL:http://delysid.org/>  <URL:http://www.staff.tugraz.at/mlang/>