There is an effort to rebase OCaml to version 4.03+ in RHEL-7 which is tracked in bug 1384533. This brltty fix is required for the rebase.

Adding the fix is fine, but as you're still building against
ocaml-4.01.0-22.7.el7_2.x86_64 this doesn't fix the bug.

In fact since IBM didn't file the required bugs to rebase OCaml,
we're not going to be fixing any of this in RHEL 7.4.

Can you also drop the advisory (from the menu on the top right
drop down button).

(In reply to Richard W.M. Jones from comment #5)
> Can you also drop the advisory (from the menu on the top right
> drop down button).

Well unless you've fix any other bugs, in which case don't do that!

(In reply to Richard W.M. Jones from comment #5)
> Adding the fix is fine, but as you're still building against
> ocaml-4.01.0-22.7.el7_2.x86_64 this doesn't fix the bug.
> 
> In fact since IBM didn't file the required bugs to rebase OCaml,
> we're not going to be fixing any of this in RHEL 7.4.
> 
> Can you also drop the advisory (from the menu on the top right
> drop down button).

Sorry, why you dropped flags on the bug which has been already approved by devels, PM and QA? The subj is:
"Add fix for brltty to compile with OCaml 4.04.0" which the patch exactly do. The subj is not "recompile with OCaml 4.04.0". Moreover the fix is correct, approved by upstream and should be already there, because the code was wrong.

(In reply to Jaroslav Škarvada from comment #7)
> Sorry, why you dropped flags on the bug which has been already approved by
> devels, PM and QA? The subj is:
> "Add fix for brltty to compile with OCaml 4.04.0" which the patch exactly
> do. The subj is not "recompile with OCaml 4.04.0". Moreover the fix is
> correct, approved by upstream and should be already there, because the code
> was wrong.

Because to fix this bug you do actually need to rebuild brltty
against OCaml 4.04, whatever the bug description might say.

I'm not against including the fix.

(In reply to Richard W.M. Jones from comment #8)
> (In reply to Jaroslav Škarvada from comment #7)
> > Sorry, why you dropped flags on the bug which has been already approved by
> > devels, PM and QA? The subj is:
> > "Add fix for brltty to compile with OCaml 4.04.0" which the patch exactly
> > do. The subj is not "recompile with OCaml 4.04.0". Moreover the fix is
> > correct, approved by upstream and should be already there, because the code
> > was wrong.
> 
> Because to fix this bug you do actually need to rebuild brltty
> against OCaml 4.04, whatever the bug description might say.
> 
> I'm not against including the fix.

No, the patch fixes the code which was wrong and as a bonus allows local recompilation with newer ocaml.

And btw you shouldn't drop flags on components which are not yours, it's impolite at least.

Created attachment 1279329 [details]
OCaml simple test

For QA how to test that the OCaml bindings works:

I suppose you do not have Braille terminal, so the following steps are for the emulator (but in case you have Braille terminal it's just a matter of different driver option):

# yum install brlapi brlapi-devel brltty-xw ocaml-brlapi
$ ocamlc -o test -I +brlapi unix.cma brlapi.cma ./test.ml
$ brltty -b xw -x no -A auth=none,host=127.0.0.1:0
$ ./test

You should see the "Hello world!" on Braille display in both ASCII and Braille for 10 seconds.

Q&A:
Is it possible to automate it?

Of course, it is! Just use the Virtual driver and replace the last two steps with:
$ brltty -b vr -d server:127.0.0.1 -x no -A auth=none,host=127.0.0.1:0
$ telnet 127.0.0.1 35752
cells 20

Now in another terminal run:
$ ./test

In the first terminal you should see the text.

Conclusion? Be happy!

Here is my improved version of the program:

--------
open Brlapi
open Unix
open Printf

let () =
  try
    openConnection settings_initializer;
    enterTtyMode tty_default "";
    writeText cursor_off "Hello world!";
    sleep 10;
    leaveTtyMode ();
    closeConnection ()
  with
  | Brlapi_error err ->
    eprintf "Brlapi_error: %s\n" (strerror err)
  | exn ->
    prerr_endline (Printexc.to_string exn)
--------

However I get an error:

$ brltty -b xw -x no -A auth=none,host=127.0.0.1:0
$ ocamlc -g -o test -I +brlapi unix.cma brlapi.cma ./test.ml
$ ./test 
Brlapi_error: Can't determine tty number

--------

strace is not very informative.  The last part is ...

socket(PF_LOCAL, SOCK_STREAM, 0)        = 3
connect(3, {sa_family=AF_LOCAL, sun_path="/var/lib/BrlAPI/0"}, 110) = -1 ENOENT (No such file or directory)
futex(0x7ffa6093e620, FUTEX_WAKE_PRIVATE, 2147483647) = 0
close(3)                                = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(4101), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0
read(3, "\0\0\0\4\0\0\0v", 8)           = 8
read(3, "\0\0\0\10", 4)                 = 4
sendto(3, "\0\0\0\4\0\0\0v", 8, 0, NULL, 0) = 8
sendto(3, "\0\0\0\10", 4, 0, NULL, 0)   = 4
read(3, "\0\0\0\4\0\0\0a", 8)           = 8
read(3, "\0\0\0N", 4)                   = 4
open("/proc/self/stat", O_RDONLY)       = 4
fstat(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffa61f08000
read(4, "5070 (test) R 5067 5067 4868 348"..., 1024) = 301
close(4)                                = 0
munmap(0x7ffa61f08000, 4096)            = 0
write(2, "Brlapi_error: Can't determine tt"..., 41Brlapi_error: Can't determine tty number
) = 41
exit_group(0)                           = ?
+++ exited with 0 +++

(In reply to Richard W.M. Jones from comment #18)
> Here is my improved version of the program:
> 
> --------
> open Brlapi
> open Unix
> open Printf
> 
> let () =
>   try
>     openConnection settings_initializer;
>     enterTtyMode tty_default "";
>     writeText cursor_off "Hello world!";
>     sleep 10;
>     leaveTtyMode ();
>     closeConnection ()
>   with
>   | Brlapi_error err ->
>     eprintf "Brlapi_error: %s\n" (strerror err)
>   | exn ->
>     prerr_endline (Printexc.to_string exn)
> --------
> 
> However I get an error:
> 
> $ brltty -b xw -x no -A auth=none,host=127.0.0.1:0
> $ ocamlc -g -o test -I +brlapi unix.cma brlapi.cma ./test.ml
> $ ./test 
> Brlapi_error: Can't determine tty number
> 

Thanks, your enhanced version also works for me. I got two warnings, but functionality is OK:
File "./test2.ml", line 7, characters 4-39:
Warning 10: this expression should have type unit.
File "./test2.ml", line 8, characters 4-31:
Warning 10: this expression should have type unit.

Could you try explicitly setting the tty number instead of using the tty_default? I will retest on cleanly provisioned machine (so far I have tested it on my "stable" system and it worked OK) and I will try to reproduce the problem.

For QA also feel free to extend the test code. I wrote this very simple test, because there were none code on the Internet (or I didn't search so hard :).

Yes it does work once I changed:

-    enterTtyMode tty_default "";
+    enterTtyMode 1 "";

So it all looks good to me.

For future reference I was testing:

  ocaml-brlapi-0.6.0-16.el7.x86_64

which is my own-built version of brltty
(see https://bugzilla.redhat.com/show_bug.cgi?id=1434818#c2)

It seems the default TTY doesn't work if I ssh to the machine. In such case the TTY number needs to be set explicitly. I am currently unsure whether it's bug or not. I will take a look.

(In reply to Jaroslav Škarvada from comment #21)
> It seems the default TTY doesn't work if I ssh to the machine. In such case
> the TTY number needs to be set explicitly. I am currently unsure whether
> it's bug or not. I will take a look.

The auto-detection routine which is enabled with the tty_default detects the controlling TTY of the calling process. With the SSH connection there is no TTY, only the PTY, so the auto-detection routine doesn't detect anything, which is probably the right behaviour (we are not running from the TTY, so there is nothing to detect). In such case you need to specify the TTY number by hand. The TTY is not important for this simple test, so arbitrary TTY can be used. The only minor problem I can see is that the brlapi documentation could be more specific about the behaviour when the auto detection fails.

Tested in:
    brltty-4.5-15.el7

* patch applied
* it builds with ocaml-4.04 

-> VERIFIED

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2179