[BRLTTY] Packaging questions

[Samuel Thibault]

Hello,

Generally speaking, note that brltty is modular: you can leave
everything as a module, and thus actual dependencies depend on which
modules you actually install.

Peter Vágner, on mer. 25 oct. 2017 17:57:59 +0200, wrote:
> I assume linux driver is specific to linux and
> there are drivers for other platforms such as Android or Windows that are not
> suitable for linux for example. Should we rather rely on auto detection here?

Yes, it's usually better not to hardcode anything.

> At-spi2 driver might be clashing with orca.

No, they can play along.

> Are there cases where it's usefull?

It allows users to use brltty as screen reader in e.g. gnome-terminal,
so it is useful.

> What about screen driver? When using linux driver and running screen on a tty
> is the screen output accessible to brltty or should both drivers be in use in
> such a case?

brltty only runs one screen driver at a time.

> Or is the screen screen driver only suitable when running on a mac
> as indicated by many of the email list discussions?

It is mostly used on mac, yes, but it could also be used on Linux,
though I don't know a real use case for this.

> linuxdoc and doxygen sound to me as they would suit well as build time
> dependencies for building the documentation. Have you a recommendation for me
> whether docs built with these two packages should be included as a part of the
> binary package? I guess doxygen docs are developer documentation for the API's
> and linuxdoc is the user documentation. Is this correct?

There is some linuxdoc for the API too. But doxygen is only for devs,
indeed.

> ncurses this would perhaps be nice to have as a runtime dependency. I can't
> really explain it so I would like to hear some supporting arguments. I guess
> it's used for better navigation in ncurses powered UI onatext console.

No, it's just useful for nice rendering support in the "tt"
pseudo-braille driver.

> Additionally there is a possible problem related to the ncurses package as
> provided in Arch linux. Recently (about two weeks ago) ncurses on arch linux
> has got these two ./configure flags enabled: --with-termlib=tinfo --with-ticlib
> =tic
> When ncurses is built like this, brltty-ttb linking fails with the error:
> /usr/bin/ld: brltty-ttb.o: undefined reference to symbol 'keypad'
> /usr/lib/libtinfo.so.6: error adding symbols: DSO missing from command line
> collect2: error: ld returned 1 exit status
> See the line 2167 of the file Programs/brltty-ttb.c. I would say we *should* be
> checking for this symbol when running ./configure and disable ncurses support
> accordingly. Or what can you suggest instead?

Disabling the use of ncurses would be a bit strong.  I'd rather
recommend disabling the only line calling keypad() in brltty-ttb.c
The real bug here, however, is that brltty assumes keypad() comes with
-lncurses, it should try to link against -ltinfo to get keypad().

> x11 libraries and extensions: Currently arch linux package only builds against
> libxaw. brltty configure script is also checking for libx11, libxtst and libxt.
> For xbrlapi and at-spi2 screen driver these are not needed I guess.

xbrlapi needs libxt to be able to simulate keypresses.

libxt is needed for the X11 pseudo braille driver (which shows a fake
X11 device)

> How does the xbrlapi xsession integration work here i.e. is this session
> agnostic meaning we can run it with whatever desktop

It is, yes. Also, the recent versions of xbrlapi behave well, i.e. it
just exits if it sees that no brltty is running.

> does this only make sense when at-spi is running?

Well, without at-spi, a blind user wouldn't be able to see the desktop

> How the xbrlapi binary gets inwoked and is it running in the background?

The Autostart/gdm/xbrlapi.desktop script can be used for gdm, and
Autostart/X11/60xbrlapi can be used for other sessions. Normally they
are already getting installed properly by "make install"

> sys/modem.h machine/speaker.h I can't find these. are these kernel dependent?

Yes.

> linux-api-headers should be added to the build time dependencies I guess.

Yes.

> Systemd is included in arch linux however pkg-config --exists libsystemd
> returns 0.

Well, yes, that's the returned value for success.

> Systemd and other dependent packages tend to put their socket files on a tmpfs
> mounted at /run on Arch linux. When I'll change the api-socket-patch from /var/
> lib/BrlAPI to let's say /run/BrlAPI . Will the clients using brlapi be able to
> locate it or this is only used within this package?

The clients which use the libbrlapi you will build with that configure
change will find the new location.  Other clients which don't use
libbrlapi, such as emacspeak, won't find it.  So it's not really
something we can move.

> What about writable directory /var/run/brltty . Are the files written there
> supposed to survive a reboot?

IIRC no.

> How does that compare with /var/lib/brltty as this is something I do
> also have on my system.

That one is used to store user preferences.

> What about libbraille it appears it's web page is down. Most likelly I won't be
> able to include that. Is it widely used?

It is not really used any more.

> dbus: Is it used in conjunction with at-spi2-core?

Yes.

> Or does it make sense to build with dbus even if at-spi2-core is not
> available?

Apparently bluetooth support uses it too.

> What is cspi support?

It was AtSpi1. It's not really useful any more nowadays.

> Script Program/brltty-genkey is not installed. Should it be and can it be done
> via included MakeFile? Are there more such scripts that might be usefull?
> We do have an install script which creates a file /etc/brlapi.key. I am just
> wondering whether we should not use what brltty provides instead of coming up
> with our own

Yes, that'd be preferrable.

> Is there a way to use braille keyboard which is part of a braille display for
> typing?

As you found out, xbrlapi :)

> I apologize for a lot of questions like this however I believe we can get this
> to rock! Imagine how cool it might be to just plugin your braille display and
> the system will be able to recognize it to activate brltty.

Yes, that's a goal we all have in mind :)

> My only problem is that I have no braille display it's why I am having
> a lot of dumb questions.  But still if possible I would like to do
> something usefull.

Note that qemu has a virtual braille device support. See e.g.
https://wiki.debian.org/DebianInstaller/Accessibility for how to use it.

Also, I don't know if you are aware of this page:

http://brl.thefreecat.org/wiki/Installer

for the installer part.

Samuel