Re: [BRLTTY] how to add support for Brltty X11 driver in Xorg session
Hello, On Sun, Apr 29, 2018 at 06:35:28PM +0200, Mgr. Janusz Chmiel wrote: > I AM using Fedora 27 Gnome and they did not include latest Brltty. That is not a problem, the atspi2 driver is in brltty since a long time. > The question is, if I do not have to also install brltty-x11 driver, You probably need this to install this kind of package to get the a2 screen driver indeed. > if it is not necessary to add X11 brltty driver inside some folder related > to Xorg server. No, it should just work by just getting fedora to install libbrlttyxa2.so along the other libbrltty in the usual place. Samuel ___ 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] how to add support for Brltty X11 driver in Xorg session
Hello, Mgr. Janusz Chmiel, le sam. 28 avril 2018 22:26:27 +0200, a ecrit: > I gues, that Brltty in X session can read editable boxes in Run command for > example. Yes. You can run it like this: brltty -b ba -x a2 -X type=all so that it will try to read everything it can from X through at-spi-2 (the a2 screen driver), and send it to the brltty daemon through brlapi (the ba braille driver). > By The way it would be very interesting project for An expert to > extent Brltty to also read other elements. Since Brltty have been made by > using C language and so fast screen reader for X environment would be great > tool. But it is complex I know that. Yes, and very much more complex than doing it in Python like Orca does. It's probably better to spend efforts on fixing Orca (its slowness is not really due to the use of Python) than rewriting another screen reader. Samuel ___ 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] New Android apk.
Hello, Mgr. Janusz Chmiel, le mer. 25 avril 2018 19:47:46 +0200, a ecrit: > I would like to thank MR Tibault and MR Mielke for this newest release of > Brltty for Android. All credits belong to Dave, I haven't worked on it ;) Samuel ___ 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] Running brltty in X11, and clipboards
Hello, While looking at brltty running in X11 with the AtSpi2 driver, the question of smooth integration with clipboards raised. While copy/pasting from the Linux console to/from X11 is not a simple matter, having a brltty instance running inside X11 with the AtSpi2 driver to copy/paste between xterms and the rest of X11 makes a lot of sense. I however see two competing approaches: - let brltty have its own clipboard as it already does, and expose it to the X11 protocol by implementing the selection behaviors. That would allow to keep the exact same behavior as on the Linux console, with the additional benefit that it can cooperate with other X11 applications. The selection behavior is however quite a beast with content type negociation etc., it's not something that can be implemented over night :) - make brltty only select text in the xterm, and let xterm do all the selection management. It'd mean to just make the brltty core call a screen driver method to notify of the selection performed by CLIP_NEW+COPY_LINE, and the AtSpi2 driver can then just notify the xterm. That doesn't allow rectangular selection, clipboard accumulation etc., but the implementation should be quite easy. What do people think? Samuel ___ 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] question about windows 10 and brltty
Hello, Velegi István, le lun. 16 avril 2018 11:11:51 +0200, a ecrit: > I can't get it work with brltty and nvda. > I have also installed brlapi but it didn't help either. Is anything actually showing up on the device, or just nothing happens? If nothing shows up, it is useless to look at the brlapi/NVDA side, since the problem is before that. Please use the "Run BRLTTY in debugging mode" start menu item, and send us the debug.log that shows up in the BRLTTY program files directory. Samuel ___ 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] Compiling BRLTTY for Android on Windows
Dave Mielke, on jeu. 08 mars 2018 10:50:59 -0500, wrote: > Yes, I'm being stubborn and maybe even unreasonable. I wouldn't say that, I have been hit with such questions of changing the build system in various projeects, and I have exactly the same position as yours :) Samuel ___ 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] Compile for Windows on Linux
Rob, on jeu. 01 mars 2018 14:35:07 -0600, wrote: > Samuel Thibault <samuel.thiba...@ens-lyon.org> wrote: > > I'd use a VM too. It is possible to install a cross-build toolchain, > > but unless your Linux distribution provides it already, it's very hairy > > to setup. > > I've got a regular toolchain set up of course. Then I found this thing called > mingw. Apparently you extract it and then you direct your makefile to the > extracted complete toolchain, set up in something like > /opt/mingw32 > or similar. This apparently has all the libraries and such you need. Then probably it is a matter of pointing brltty's configure to the proper paths & compilers etc. We have never done this for windows so you're a bit on your own on this one :) We however are used to cross-compiling for MS-DOS, so you could find useful guidelines in Documents/README.DOS' "Building BRLTTY" section. Samuel ___ 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] Compile for Windows on Linux
Dave Mielke, on jeu. 01 mars 2018 15:10:53 -0500, wrote: > [quoted lines by Rob on 2018/03/01 at 13:18 -0600] > >What do I need to have installed so I can compile a .exe suitable for > >windows using the latest BRLTTY release? I've never built windows software > >on Linux. > > I don't know. I myself use a Windows VM to build it. I'd use a VM too. It is possible to install a cross-build toolchain, but unless your Linux distribution provides it already, it's very hairy to setup. Samuel ___ 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] Any chance of supporting 64-bit Cygwin?
Hello, Yes, it took a very long time, but... Siju Samuel, on mar. 11 févr. 2014 17:40:30 -0600, wrote: > In windows, simultaneous read [with 1 option as input] and write [ > (brlapi_readKey(1, ) , brlapi_write()] using different thread was not > working. Currently brlapi_write() will block till a physical Key is pressed, > before performing write. If you find time it would be really helpful to > use > brlapi. We have revamped the way reads are done, which made us set FILE_FLAG_OVERLAPPED, which AIUI, avoids some of the windows synchronization issues. Samuel ___ 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] Translating unicode characters with brltty
Vikash Kesarwani, on dim. 18 févr. 2018 09:02:25 +0530, wrote: > It would be great if you can give some reference to how can I generate these > fonts. I have just uploaded the tool on http://http.debian.net/debian/pool/main/c/console-braille/console-braille_1.7.tar.gz Samuel ___ 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] Translating unicode characters with brltty
Hello, Vikash Kesarwani, on jeu. 15 févr. 2018 10:41:50 +0530, wrote: > I actually want only to read it in braille through brltty, it does not matter > if it is displayed correctly on console. Ok, then you can try to make your Linux distribution use one of the attached font, depending which font size your system is already using (probably a 16 pixel font). If your system uses another font size than 8 and 16, I can easily generate it too. Samuel devanagari8.psf Description: Binary data devanagari16.psf Description: Binary data ___ 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] Brltty in Ubuntu.
Dave Mielke, on jeu. 15 févr. 2018 10:23:39 -0500, wrote: > I myself don't see having different distributions put brltty into different > places is helpful, so maybe this is a good time to rediscuss the issue. I have actually just changed Debian to put brltty in /bin. IIRC it was in Debian in /sbin just because originally it was in /sbin and we hadn't taken the time to change the path. So I believe we can just stay in /bin for good :) Samuel ___ 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.6 is now released.
Hello, Dave Mielke, on dim. 11 févr. 2018 14:59:02 -0500, wrote: > Could you please try changing that AC_PATH_PROG (line 353 of configure.ac) to > AC_PATH_TOOL (same syntax) as perhaps a simpler way of resolving the problem? That seems to be working fine indeed. Samuel ___ 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.6 is now released.
Hello, Dave Mielke, on lun. 05 févr. 2018 12:02:34 -0500, wrote: > Release 5.6 of brltty is now available. While working on the Debian package, I got the following warning which got recently added to Debian: autotools-pkg-config-macro-not-cross-compilation-safe The package appears to use AC_PATH_PROG to discover the location of pkg-config(1). This macro fails to select the correct version to support cross-compilation. A better way would be to use the PKG_PROG_PKG_CONFIG macro from pkg.m4 and then using the $PKG_CONFIG shell variable. Refer to https://bugs.debian.org/884798 for details. Although properly detecting pkg files for cross-compilation may not be a priority target, it could be useful to fix it :) Samuel ___ 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] Translating unicode characters with brltty
Hello, Vikash Kesarwani, on sam. 10 févr. 2018 08:41:48 +0530, wrote: > 1. I am unable to display unicode characters (hindi) on virtual terminal You need to load a devanagari PSF font. I have however not seen one in the usual console font packages, so you would probably have to convert one or create it from scratch. If you only care about being able to read it in braille and not actually show it on the physical screen, we can easily create a dumb font to do that. > 2. How do I tell brltty to read unicode and translate. That will "just work" once the font is set up correctly and you configure brltty to use the hindi (hi) braille table (actually the devanagari table). Samuel ___ 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] mlterm
Aura Kelloniemi, on jeu. 25 janv. 2018 10:23:46 +0200, wrote: > But yes, a better interface would be great. The best way probably would be > through BrlAPI No, because that assumes braille. There can be speech-only screen readers too, and whatnot. Also, there is nothing related with brlapi, actually :) So better have another client/server mechanism. > - brltty would just support new functions for clients to > provide virtual screen contents and ways to update it. This of course would be > slower than shared memory, but this would work across the internet too. This > interface should be designed such that it will be possible to extend it. Well, actually it already exists, it's called AT-SPI2. It's based on dbus and brings quite a few abstractions. ATM it proposes a Text-based interface, which means insertion/suppression events which make it quite complex. A Terminal-based interface was designed, but never actually implemented. We could use that. > My wish would actually be that all screen driver modules were converted to > BrlAPI clients. What benefit would it bring? > Maybe BRLTTY itself could be a BrlAPI client which would > communicate with the lowest level braille-daemon which only talks to the > hardware devices and with clients providing raw content to be displayed. It can already act as such: it's the ba driver. > Great... BRLTTY could do this and that, however, there is one question though. > Is there anybody who has the time, skills and interest to implement any of > this? That's the problem indeed. > My gut feeling is that mlterm has been reimplementing BRLTTY's features > exactly because of lack of interface (and people who are familiar with > BRLTTY's codebase). So maybe this is the way to do it for now. Well, the time it took to reimplement all of that could have been used to implement an interface instead... Samuel ___ 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] mlterm
Hello, Didier Spaier, on jeu. 25 janv. 2018 00:17:52 +0100, wrote: > $ mlterm -v > mlterm version x.x.x > Features: ... brlapi So they reimplemented a screen reader within mlterm, and exposed the content through brlapi. That's not really the best way to do this: it means all the navigation features that brltty provides are either reimplemented in mlterm (thus duplicate code), or missing. There should rather be a standard way for fb terms to expose their content to brltty, similarly to how the kernel exposes the VT content through /dev/vcs* Samuel ___ 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 routing cursor with xw driver
Shérab, on sam. 16 déc. 2017 17:00:42 +0100, wrote: > For instance, have you already tried clicking on a character with the > left button of your mouse? Isn't this creating a cursor routing event? AFAIR, that's how you can get cursor routing, yes. Samuel ___ 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] Support for word wrapping in brltty
Hello, Peter Vágner, on mar. 07 nov. 2017 16:38:33 +0100, wrote: > Is this recently introduced word wrap mode also usefull when brltyy is used by > other apps such as orca via brlapi? No, Orca uses liblouis for braille transcription.. > Orca users wish to have word wrapping working and there were some discussions > on the orca list suggesting it might be added by relying more on liblouis. Yes, that's a saner way. Samuel ___ 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] Packaging questions
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.
Re: [BRLTTY] BrlAPI in Windows
Hello, Lars Bjørndal, on ven. 27 oct. 2017 21:54:02 +0200, wrote: > > Lars Bjørndal, on lun. 23 oct. 2017 21:13:14 +0200, wrote: > > > I have cygwin 64bit installed, and I've compiled BRLTTY. > > > > Is there are reason for not using the pre-built BRLTTY? > > Well, I thought, as I use BRLTTY in the Cygwin environment to use SSH, > I thought a compiled version in that environment was the most memory > efficient. That may be totally wrong. A cygwin version is never more memory efficient than a native windows version :) Cygwin has to do a lot to simulate a Linuxish environment for the application. Samuel ___ 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] terminal control codes
Hello, Brian Tew, on ven. 27 oct. 2017 04:31:30 -0500, wrote: > When I start it the output is full of terminal control codes. > I tried changing TERM from linux to vt100, same problem. I'm afraid it actually hardcodes the escape sequences being used. > Any ideas on what I might try? Thanks. You could try running it in screen. Samuel ___ 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] Brltty and Super key etc
Mika Hanhijärvi, on ven. 20 oct. 2017 18:55:56 +0300, wrote: > Ok thanks . That explains why I have not found any way to use Super key. I was talking about the Fn key, not the Super key. The super key should be synthesizable. Samuel ___ 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] Brltty and Super key etc
Hello, Mika Hanhijärvi, on ven. 20 oct. 2017 18:41:23 +0300, wrote: > 6) Fn key I can speak for this one: it's not possible, because it is a key which is handled by the BIOS of the PC itself, software does not see it. So it can't be synthesized. Others should be possible to synthesize. Samuel ___ 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] Unable to get sliding braille window working
Hello, Vikash Kesarwani, on sam. 14 oct. 2017 15:04:49 +0530, wrote: > Hi, I am unable to get sliding window feature working. I have enabled it, but > still when cursor moves too near to either end (even at the last cell) it does > not slide the braille window. Is this in textmode with BRLTTY or in graphical mode with Orca? Samuel ___ 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] Crash when sending char é ú?
Hello, Quartel, Eric de, on sam. 30 sept. 2017 15:39:24 +, wrote: > In the source code add >setlocale(LC_ALL, "nl_NL.UTF-8"); And then it was working? We would still be interested in knowing what is crashing without this line, because this is really not supposed to happen and means there is a bug somewhere which we have to fix, and for now this line is only hiding it, not fixing it :) Samuel ___ 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] Crash when sending char é
Hello, Quartel, Eric de, on jeu. 28 sept. 2017 11:37:03 +, wrote: > Unfortunate when the é (e with acute accent) is send - brlapi_writeText(0,"my > string with é in it") - my program crashes. Did you initialize locales (using setlocale) according to the encoding you use for é? Normally it shouldn't crash, but perhaps that's the underlying issue. Samuel ___ 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] Issue linking brlapi and orca.
Dave Mielke, on ven. 15 sept. 2017 08:23:39 -0400, wrote: > [quoted lines by Didier Spaier on 2017/09/15 at 14:14 +0200] > >2017-09-15@14:05:53.157 [brltty] BRLTTY 5.5 rev unknown [http://brltty.com/] > >2017-09-15@14:05:54.201 [brltty] Linux Screen Driver: > >2017-09-15@14:05:54.202 [brltty] NoSpeech Speech Driver: > > Samuel: I don't see the braille driver being started. We made a change not > too > long ago to not start the server until the braille driver starts successfully > for the first time. Ah :/ One way is to run e.g. brltty -b tt -d /dev/tty12 And you'll see the braille output on the Linux VT number 12. Samuel ___ 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] Issue linking brlapi and orca.
Hello, Didier Spaier, on mer. 13 sept. 2017 11:42:11 +0200, wrote: > Le 13/09/2017 à 10:06, Samuel Thibault a écrit : > > John Covici, on mer. 13 sept. 2017 03:59:06 -0400, wrote: > >> Is the line in your /etc/brltty.conf uncommeted > >> api-parameters Auth=keyfile:/etc/brlapi.key # Require authentication > >> key > >> > >> Its near the end of the file and is necessary for orca to work as of > >> now. > > > > ? That shouldn't be. Normally, either polkit or the keyfile is needed. > > Which version seems to require that? I remember we had to fix it at some > > point, but did a version got released with the issue? > > Anyway uncommenting it doesn't help here. > > I am ready to provide a log. How should I set the logging options? Normally the logs should already contain the errors. It may still be useful to pass -l server to brltty. But just to make sure: is there really no /var/lib/BrlAPI/0 file? Samuel ___ 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] Issue linking brlapi and orca.
John Covici, on mer. 13 sept. 2017 03:59:06 -0400, wrote: > Is the line in your /etc/brltty.conf uncommeted > api-parameters Auth=keyfile:/etc/brlapi.key # Require authentication > key > > Its near the end of the file and is necessary for orca to work as of > now. ? That shouldn't be. Normally, either polkit or the keyfile is needed. Which version seems to require that? I remember we had to fix it at some point, but did a version got released with the issue? Samuel ___ 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] Issue linking brlapi and orca.
Didier Spaier, on mer. 13 sept. 2017 09:47:29 +0200, wrote: > Le 13/09/2017 à 01:38, Samuel Thibault a écrit : > > Didier Spaier, on mer. 13 sept. 2017 01:13:03 +0200, wrote: > >> brlapi.ConnectionError: couldn't connect to b':0' with key > >> b'polkit+keyfile:/etc/brlapi.key': b'connect: Aucun fichier ou dossier de > >> ce type' > > > > Note: it's the connect operation which fails. It needs a directory > > /var/lib/BrlAPI to be 1777, so brltty can create its socket there. > > Yes, but: > --- > didier[~]$ stat /var/lib/BrlAPI/ > Fichier : '/var/lib/BrlAPI/' >Taille : 4096 Blocs : 8 Blocs d'E/S : 4096 > répertoire > Périphérique : 813h/2067d Inœud : 2093281 Liens : 2 > Accès : (1777/drwxrwxrwt) UID : (0/root) GID : (0/root) > Accès : 2017-09-13 00:22:21.0 +0200 > Modif. : 2017-09-13 00:20:31.0 +0200 > Changt : 2017-09-13 00:22:21.749256943 +0200 > Créé : - > --- > > This file was created installing brltty 5.5 Ok, then does it contain a file called 0 while brltty is running ? If not, we need to check the brltty logs for error about that. Samuel ___ 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?
Hello, Dave Mielke, on dim. 20 août 2017 11:36:28 -0400, wrote: > [quoted lines by Shérab on 2017/08/20 at 11:26 +0200] > > >I share Samuel's fear that is will be difficult to design something > >which is generic enough. What can we do beyond returning the keycodes > >themselves or brltty commands, as we currently do? > > What I suspect we need is a set of commands that reflect how one works within > a > graphical environment (perhaps things like hierarchical window navigation, > going to the navigation root window (home screen), going up one level, etc). > Then we could design key tables for that, and brltty (and via BrlAPI) could > be > used to naturally work within that environment. Well, I'm wondering whether it's really to be done and maintained within brltty, and not just within Orca, which is what knows what it wants to do. Brltty exports commands just because it happens to have them. If some client likes the way it is, then it can use them, and otherwise, I don't think brltty can really provide something that would be good, compared to defining key tables on the client side. Samuel ___ 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] Typing all characters Focus 40
Hello, Frans-Willem Post, on ven. 18 août 2017 20:40:41 +0200, wrote: > For example: I can type 'a' using Dot1, 'A' using Dot1+Dot7, '1' using > Dot1+Dot6 and 'á' using Dot1+Dot6+Dot8 - but not 'ë' using > Dot1+Dot2+Dot4+Dot6+Dot8. Why not? Can ë be typed directly on your keyboard, or do you need e.g. to presse a dead-diaeresis, then e? That's a current shortcoming of key simulation that they simulate only one keypress (possibly with modifiers). Samuel ___ 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?
Hello,
Mario Lang, on jeu. 27 juil. 2017 21:17:15 +0200, wrote:
> >> The documentation of "Raw keycode" mode does explicitly state that
> >> brlapi_acceptKeyRange() is not necessary.
> >
> > Yes, I know.
>
> Either the documentation or the code needs to be fixed.
> I would vote for making the code do what the documentation claims.
Agreed :)
The attached patch is probably correct.
Samuel
diff --git a/Programs/brlapi_server.c b/Programs/brlapi_server.c
index aae04ca16..bed399089 100644
--- a/Programs/brlapi_server.c
+++ b/Programs/brlapi_server.c
@@ -2476,7 +2476,9 @@ finished:
/* to let the user read the screen in case theree is an error */
static int initializeAcceptedKeys(Connection *c, int how)
{
- if (how != BRL_KEYCODES) {
+ if (how == BRL_KEYCODES) {
+if (c && addKeyrange(0, BRLAPI_KEY_MAX, >acceptedKeys) == -1) return -1;
+ } else {
if (c) {
typedef struct {
int (*action) (brlapi_keyCode_t first, brlapi_keyCode_t last,
KeyrangeList **list);
___
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] Issues with an Easy Braille
Err, just realizing... The bug was with Vario Ultra :) But perhaps there's the same with Easy, and the quirk has to be extended. Samuel ___ 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] Issues with an Easy Braille
Alex Bernier, on jeu. 20 juil. 2017 15:44:35 +0200, wrote: > On Thu, Jul 20, 2017 at 08:13:32AM -0500, Samuel Thibault wrote: > > Alex Bernier, on jeu. 20 juil. 2017 11:52:06 +0200, wrote: > > > I just recieved a new Easy Braille (Handy Tech). My old one works > > > perfectly with BRLTTY but there are some issues with the new one : > > > display is very slow, the keyboard does not work and the driver is > > > frequently reinitialized. > > > > Which Linux kernel version are you using? > > 4.11.0-1-amd64 #1 SMP Debian 4.11.6-1 (2017-06-19) x86_64 GNU/Linux So it should have the fix, hum... Could you send the output of lsusb -v ? > > This looks very much like > > a bug we had to get fixed there because of a bug in the device. (Or > > an option is to plug the device throught a USB 1.0 hub). It should be > > available in Linux 4.11 and above, stable 4.10.7 and above, stable > > 4.9.19 and above, stable 4.4.58 and above, and stable 3.18.49 and above. > > Where should the bug be fixed : in the kernel, in BRLTTY ? Or in the braille > display firmware ? Ideally, in the braille display firmware. I had contacted the manufacturer, no answer so far. Thus we added a quirk to Linux. Samuel ___ 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] Issues with an Easy Braille
Hello, Alex Bernier, on jeu. 20 juil. 2017 11:52:06 +0200, wrote: > I just recieved a new Easy Braille (Handy Tech). My old one works perfectly > with BRLTTY but there are some issues with the new one : display is very > slow, the keyboard does not work and the driver is frequently reinitialized. Which Linux kernel version are you using? This looks very much like a bug we had to get fixed there because of a bug in the device. (Or an option is to plug the device throught a USB 1.0 hub). It should be available in Linux 4.11 and above, stable 4.10.7 and above, stable 4.9.19 and above, stable 4.4.58 and above, and stable 3.18.49 and above. Samuel ___ 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] auth server refuses to start if built without polkit
Chris Brannon, on jeu. 06 juil. 2017 06:26:37 -0700, wrote: > The polkit method descriptor initializes just fine. But for whatever > reason, polkit authentication doesn't work on the user's system. We > could still fall back to keyfile. Yes, we need that fallback. Samuel ___ 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] auth server refuses to start if built without polkit
Chris Brannon, on mer. 05 juil. 2017 09:39:29 -0700, wrote: > Seems like this would be fixed with a pretty simple > change to Programs/brlapi.h.in. I can send a patch if you like. Please do :) The most time-consuming part is actually testing the patch, which I guess you'll do, so the contribution is welcome :) Samuel ___ 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] Python bindings - 3.6
Hello, Gwyn Ciesla, on ven. 16 juin 2017 11:02:13 -0500, wrote: > We've been having trouble building the python bindings for python 3.6, > using both brltty 5.4 and 5.5. > What information would be helpful in chasing this down? Well, all available build logs, for a start :) Samuel ___ 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] Re : Re: htdoc
MENGUAL Jean-Philippe, on mer. 14 juin 2017 13:57:41 +0200, wrote: > Yes I remember, but I dont find it. So I dont know if it is free, or not, > etc. And ok to review and test, if I find some way to get it. Well, it's a matter of discussing with the manufacturer. Samuel ___ 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] htdoc
MENGUAL Jean-Philippe, on mer. 14 juin 2017 11:56:16 +0200, wrote: > I will have the device with me next Sunday afternoot in Paris. What kind of > info would be relevant to start writing a htdoc for Linux? Would someone be > interested? Or should we request this to Handytech? As I said earlier in the thread, HandyTech did use to have a linux version of htcom. That just needs to be revived. Samuel ___ 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] WG: Handytech displays question
Hello, Felix Grützmacher - Help Tech GmbH, on mar. 06 juin 2017 09:08:31 +0200, wrote: > - Use HTCom, which is available for Windows. That reminds me... There used to be a htcom version for Linux developped by Halim Sahin, does it not exist any more? Samuel ___ 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 the NVDA fix and the MS libusb update.
Dave Mielke, on dim. 09 avril 2017 14:54:53 -0400, wrote: > Both the NVDA fix and the MS update to libusb can be tested via the > brltty-win-5.4-233 files that are now available on brltty's download page. > > Please test soon as 5.5 will most likely be released in a little over a week > from now. In my windows XP tests, it seems to work fine in 32bit/64bit, libusb-win32/libusb-1.0, and with NVDA. Samuel ___ 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 the NVDA fix and the MS libusb update.
Dave Mielke, on dim. 09 avril 2017 15:07:02 -0400, wrote: > [quoted lines by Samuel Thibault on 2017/04/09 at 21:04 +0200] > >Could you provide both a libusb-win32 and a libusb-1.0 build? Depending > >on the USB situation, one or the other may work better. > > Already done. Ok, I should have actually checked :) Thanks, Samuel ___ 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 the NVDA fix and the MS libusb update.
Dave Mielke, on dim. 09 avril 2017 14:54:53 -0400, wrote: > Both the NVDA fix and the MS update to libusb can be tested via the > brltty-win-5.4-233 files that are now available on brltty's download page. Could you provide both a libusb-win32 and a libusb-1.0 build? Depending on the USB situation, one or the other may work better. Samuel ___ 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
Hello, Samuel Thibault, on dim. 09 avril 2017 17:38:11 +0200, wrote: > Looking more at this... I can confirm that with these changes, I could run brltty fine on windows XP 64. It seems it works fine with our previous .inf file, but I guess with more recent versions of windows, the 64bit version of the driver is required, so these changes should go in. Samuel ___ 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
Looking more at this... Mario Lang, on ven. 07 avril 2017 21:38:16 +0200, wrote: > 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 Yes, it makes sense, the 32bit driver (libusb0.sys) is probably not useful on 64bit windows. > @@ -55,7 +55,7 @@ libusb0.dll > libusb0.dll > > [libusb_files_dll_x64] > -libusb0.dll,libusb0_x64.dll > +libusb0_x64.dll I don't really know. I'd tend to think that one wants to have the 32bit version of the dll too, but we ship it along brltty.exe already anyway. I'd say "can not hurt", then. > @@ -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 Yes, that makes sense, we want the 64bit driver, not the 32bit driver. Samuel ___ 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
Hello, Mario Lang, on ven. 07 avril 2017 21:38:16 +0200, wrote: > 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? I don't really know. I can only say that the patch makes sense to me, and I guess they did it to fix something. > --- 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 > + > + ___ 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
Felix Grützmacher - Help Tech Elektronik GmbH, on jeu. 06 avril 2017 16:26:43 +0200, wrote: > I'm trying to find out if Microsoft may have > patched the version of BRLTTY that's downloaded automatically when they > install Braille support. 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). Samuel ___ 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] Accessibility topic of LSM 2017
LSM/RMLL 2017 17th Libre Software Meeting July 1-7, 2017 Saint-Etienne, France http://2017.rmll.info/ Call For Papers and Participation limited to accessibility topic [we apologize for duplicate receipt of this message] Last call before deadline : march *31st* 2017 Sharing of knowledge, freedom of information, community spirit, exchange of ideas, technological progress: every year the Libre Software Meeting (LSM) follows the Libre philosophy. RMLL/LSM is a non-commercial series of conferences, round tables discussions and practical workshops based on Libre/Free Software and its uses. Its aim is to provide a platform for Libre/Free Software users, developers and stakeholders. Access to LSM is free of charge and open to everyone. The conference will be held in Beauvais from July 1st to July 7, 2017. We hereby announce the opportunity to submit papers for selection by the technical review committee for the RMLL/LSM 2017. This year again we would like to put a particular emphasis on accessibility on the whole RMLL/LSM event. We will have our usual workshop, as described below, but we would like to have accessibility talks held in other sessions too, if possible all of them, as was achieved in 2010 in Bordeaux. We thus invite you to submit your accessibility talks to various topics, so as to broaden the audience of accessibility questions. Concerning our dedicated accessibility workshop, to better target the various exchanges that will be taking place, the programme committee of the accessibility workshop proposes several kinds of meetings: - "Solution" meetings, with conferences and round tables to present solutions dedicated to previous areas. - "State of the art" conferences between practitioners, developers, scientists and users to discuss about what exists according to the specific needs of users, what works well or a little less well, to talk about approaches... - "Technical" presentations between developers and scientists. This will allow initiation of exchanges between communities that do not necessarily have the opportunity to meet and will maybe lead to new collaborations or projects. Finally, a workshop area will be available to try out and exchange tools presented by their authors or by seasoned users of those solutions. Information on workshops from last event is available on - https://2015.rmll.info/accessibilite Information on the previous global RMLL/LSM emphasis on accessibility in 2010 is available on - http://2010.rmll.info/+-Accessibilite,2-+.html You will be able to attend conferences on other related issues such as "System Administration" (like Nagios, GLPI, Cfengine, ...), "Development" (like NoSQL, Lucene, GCC, ...), "Law" (like Licenses,OpenData, FSF, ...), "Internet" (WebGL, Jabber, Typo3, ...), ... Conferences from last year are available on : - https://2015.rmll.info/conferences-et-ateliers If you are interested in participating, please have a look at the topics presentation on https://2017.rmll.info/pages/themes.html and submit your presentation at: https://2017.rmll.info/cfp/talk/new Please feel free to share this information with others people who may be interested. We welcome your participation and input and look forward for a valuable meeting. Deadlines = The following dates are important if you wish to participate to the call for papers. Abstract submission: no later than 31st of March 2017 Submission guidelines Speakers should submit an abstract in English or French ; about 400 words, and in 2 languages if possible. If accepted, this abstract will be published on the website. Submissions should be submitted via this form: https://2017.rmll.info/cfp/talk/new Submissions should also include the following: * Contact information and Geographical location of presenter (country of origin/passport). * A brief biography. * Any significant presentation and/or educational experience/background. * For technical topics: Reason why this material is innovative, significant or an useful tutorial. * Optionally, any outlines or samples of prepared materials. * Information whether the submission has already been presented, and if so, where. Personal information will be used exclusively for the sole purpose of the RMLL/LSM committee and shall not be shared with third parties. If the paper is not accepted for the main session, it may be accepted for a short-form or "lightning talk" session. Travel Assistance Non-commercial and based upon volunteer work, RMLL/LSM are events with limited resources. However, speakers who exhibit particular need may receive a refund for their transportation charges at the discretion of the selection committee. If you know the estimated cost of the transportation, providing this will make it easier for
Re: [BRLTTY] Braille displays vs. USB-to-serial adapters
Hello, Mike Gorse, on Tue 07 Feb 2017 17:18:35 -0500, wrote: > I'm wondering if applying the patch from upstream would be enough to keep > brltty from doing this. I'm guessing not, since it appears that Hims and > HandyTech displays have their manufacturer set to "FTDI", which I'd think > would make them indistinguishable from standalone USB-to-serial adapters, Yes. But at least distinguishable from FTDI chips integrated in some boards. > but debian still has a udev rule that starts brltty if one of these devices > with "FTDI" as its manufacturer is connected, Yes, but only in the installer. Installed systems don't have that udev rule. Samuel ___ 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] Change input TTY in BRLTTY
Hello, Vikash Kesarwani, on Mon 02 Jan 2017 05:15:02 -0800, wrote: > So my question is, is there a way to change input tty of BRLTTY > typographically/ dynamically on runtime. Do you mean, making BRLTTY read/write on a different virtual terminal than the one which is currently displayed? Samuel ___ 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
