[BRLTTY] BrlAPI and contiguous displays
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 http://debian.org/>
.''`. | Get my public key via finger [EMAIL PROTECTED]
: :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
`. `'
`- http://delysid.org/> http://www.staff.tugraz.at/mlang/>
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@mielke.cc
For general information, go to: http://mielke.cc/mailman/listinfo/brltty
[BRLTTY] -b auto -d usb:
Hi. Our current implementation of -b auto on the USB bus does work, but it is pretty inefficient. This gets extremely obvious if one tries to run brltty in auto-detection mode on a small embeeded-type device, like ARM based machines running Linux. While BRLTTY is idling and trying to find a braille display, it consumes a lot of CPU time. Even on not so small systems you can notice the performance hit. On a 2.8GHz machine of mine, brltty consumes 4% cpu every few seconds when watched with top. This is because we are iterating the whole USB for every single driver that supports USB devices. Can we think of a way to collect relevant USB IDs in autodetection mode beforehand, and do the iterating just once? Alternatively, can we perhaps cache USB device tree information during a cycle of driver open attempts? -- CYa, Mario | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
[BRLTTY] [PATCH] [Python] returnerror cdef to def ?
Hi. Currently, GCC emits a warning regarding a statment without effect in the python bindings that comes from the definition of returnerror. returnerror is currently defined as a cdef. cdef does not really support docstrings in pyrex (why should it). On second glance however, returnerror is only called in python context. I propose to change the definition to a normal def, and make it simpler. The warning is gone afterwards, only one remining from the __init__ docstring in the cdef class Connection (why would a cdef have a python docstring?). Can the API maintainers review please? Index: Bindings/Python/brlapi.pyx === --- Bindings/Python/brlapi.pyx (revision 3058) +++ Bindings/Python/brlapi.pyx (working copy) @@ -52,11 +52,9 @@ cimport c_brlapi include "constants.auto.pyx" -cdef returnerrno(): +def returnerrno(): """This function returns str message error from errno""" - cdef c_brlapi.brlapi_error_t *error - error = c_brlapi.brlapi_error_location() - return c_brlapi.brlapi_strerror(error) + return c_brlapi.brlapi_strerror(c_brlapi.brlapi_error_location()) class ConnectionError: """Error while connecting to BrlTTY""" -- CYa, Mario | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
[BRLTTY] missing error checks?
Hi. The following python session is reproducible for me with latest svn: Python 2.4.4 (#2, Apr 25 2007, 22:41:41) [GCC 4.1.3 20070423 (prerelease) (Debian 4.1.2-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import brlapi >>> c = brlapi.Connection() >>> c.enterTtyMode(2) 2 >>> c.readKey(1) 536870914L >>> c.write(text="Hello") 0 >>> c.readKey(1) BrlAPI exception: Invalid packet on Write request of size 13 (04 00 00 00 00 00 00 05 48 65 6c 6c 6f) You may wish to add the -ldebug option to the brltty command line in order to ge t additional information in the system log Aborted This should not really happen. I guess the error comes from too few parameters to write(). -- CYa, Mario | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
[BRLTTY] Building outside the source directory
Hi. I can not build BRLTTY outside its source directory. To reproduce, do the following: $ mkdir build && cd build && ../configure && make The patch below fixes the problems with the drivers, but the python bindings still fail. The problem is inclusion paths: brlapi_keycodes.h and brlapi_constants.h are included without their Programs/ prefix, and therefore the SRC_TOP/Programs and BLD_TOP/Programs directories need to be added to CFLAGS since BLD_TOP/Programs contains the generated brlapi_constants.h. Can please someone look at this and confirm it is the right way to approach it, and maybe figure out how to make the python bindings follow suit? Index: config.mk.in === --- config.mk.in(revision 3080) +++ config.mk.in(working copy) @@ -33,7 +33,7 @@ INSTALL_ROOT = @install_root@ EXECUTE_ROOT = @execute_root@ -EXTRACFLAGS = -I$(BLD_DIR) -I$(BLD_TOP:/=) -I$(SRC_DIR) -I$(SRC_TOP:/=) @SYSCFLAGS@ @DEFS@ +EXTRACFLAGS = -I$(BLD_DIR) -I$(BLD_TOP:/=) -I$(BLD_TOP:/=)/Programs -I$(SRC_DIR) -I$(SRC_TOP:/=) -I$(SRC_TOP:/=)/Programs @SYSCFLAGS@ @DEFS@ YACC_CFLAGS = @YACC_CFLAGS@ HOSTCC = @CC@ -- CYa, Mario ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
[BRLTTY] [PATCH] Support for Handy Tech Easy Braille
Hi. Thanks to a really nice co-operation between display manufacturer Handy Tech[1] from Germany and a reseller company named Transdanubia[2] From Vienna, support for all (line-based) braille products of Handy Tech is now complete with this patch which adds support for the Easy Braille[3]. This display has 10 keys, arranged like on many other Handy Tech products to resemble an 8-dot braille keyboard with two space keys. The two space keys are very large and can easy be hit with the thumb. InputMode is also supported on this model, simply hit B1+B8+DN to enable, and B1+B8+UP to switch back to navigation mode. In InputMode, the left space key becomes the control modifier and the right space key can be used to simulate Alt. All in all, this baby is extremely small. Its in the same size-category as the Papenmeier Slimline series or the BAUM Vario products. However, it (especially the keys) feels very robust despite the small size. Personal comment, I really like it. Thanks go out to Handy Tech and Transdanubia for continuously providing me with samples of their new models. All the shipment and/or transportation costs to get hardware to me (and back) were (and are) sponsored by these two companies, and they have always been extremely helpful with any problems that might have come up. [1] http://www.handytech.de/ [2] http://www.tsb.co.at/ [3] http://www.handytech.de/en/normal/products/for-blind/easy-braille/index.html pgpnxXzAVLDEd.pgp Description: PGP signature Index: BrailleDrivers/HandyTech/Makefile.in === --- BrailleDrivers/HandyTech/Makefile.in (revision 3088) +++ BrailleDrivers/HandyTech/Makefile.in (working copy) @@ -17,7 +17,7 @@ DRIVER_CODE = ht DRIVER_NAME = HandyTech -DRIVER_COMMENT = Modular 20/40/80, Modular Evolution 64/88, Braille Wave 40, Braille Star 40/80, Bookworm, Braillino 20 +DRIVER_COMMENT = Modular 20/40/80, Modular Evolution 64/88, Braille Wave 40, Easy Braille, Braille Star 40/80, Bookworm, Braillino 20 DRIVER_VERSION = 0.4 DRIVER_DEVELOPERS = Andreas Gross <[EMAIL PROTECTED]>, Dave Mielke <[EMAIL PROTECTED]>, Mario Lang <[EMAIL PROTECTED]> HELP_DEPS = $(HELP_TEXT) Index: BrailleDrivers/HandyTech/help4.txt === --- BrailleDrivers/HandyTech/help4.txt (revision 0) +++ BrailleDrivers/HandyTech/help4.txt (revision 0) @@ -0,0 +1,77 @@ +BRLTTY Help for Handy Tech Easy Braille Displays +From left to right, the front keys are: B1 B2 B3 B4 UP DN B5 B6 B7 B8 + +Movement Commands: +UPgo left one window +DNgo right one window +B1go to cursor +B1 UP go to left end of line +B1 DN go to right end of line +B2go to top-left corner +B2 UP go to top line +B2 DN go to bottom line +B3go to last motion +B3 UP go left half window +B3 DN go right half window +B6 UP go left one character +B6 DN go right one character +B4go up one line +B5go down one line +B4 b1 go up to last line of previous paragraph +B5 b1 go down to first line of next paragraph +B4 b2 go up to previous command prompt +B5 b2 go down to next command prompt +B4 b3 go up to previous line containing cut buffer +B5 b3 go down to next line containing cut buffer +B4 b6 go up to nearest line with different highlighting +B5 b6 go down to nearest line with different highlighting +B4 b7 go up several lines +B5 b7 go down several lines +B4 b8 go up to nearest line with different content +B5 b8 go down to nearest line with different content + +Modes and Features: +b8toggle help mode +B8 B1 toggle cursor tracking +B8 B2 toggle show cursor +B8 B3 toggle show attributes +B8 B6 toggle frozen screen +B8 B7 toggle alert tunes +B7toggle six-dot braille +B7 B1 toggle preferences menu +B7 B2 load saved preferences +B7 B3 save preferences +B7 B6 toggle info mode +B6toggle display attributes +B6 B1 toggle skip identical lines +B6 B2 toggle skip blank windows +B6 B3 toggle sliding window + +Routing Key Commands: +Rnbring cursor to character +B1 Rn bring left end of window to column +B2 Rn describe character +B3 Rn append to cut buffer from character +B4 Rn start new cut buffer from character +UP Rn go up to line not indented more than column +DN Rn go down to line not indented more than column +B5 Rn rectangular cut to character +B6 Rn linear cut to character +B7 Rn set mark +B8 Rn go to mark + +Miscellaneous Commands: +UP DN paste cut buffer at cursor position +B2 B3 UP stop speaking +B2 B3 DN say current line +B1 B8 UP switch to navigation mode (the default) +B1 B8 DN switch to input mode + +The front keys, when in input mode, are interpreted differently. The eight Bn +keys are interpreted as the eight braille dots; pressing any combination o
[BRLTTY] A data-point for the USB problem investigation
Hi. Just to let you know, I am running Linux 2.6.21 on Debian unstable (sid) on a x86_64 machine. I am currently using a serial display on that machine, but the Easy Braille for which I just implemented support is a USB display and that worked completely flawlessly here. In other words, I can not reproduce so far that 2.6.21 is supposed to have problems with USB displays. I am guessing the problem we heard about on this list is specific to some particular piece of hardware. -- CYa, Mario ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] How to make brltty to suport ms-dos?
Lars Bjørndal <[EMAIL PROTECTED]> writes: > On Tue, Jul 03, 2007 at 09:55:14PM +0200, Samuel Thibault wrote: >> Note: it only works with serial devices with speed <= 9600bps. > > So it won't work with one of Handy Tech's braille displays? (I think > they're using 19200, right?) Yes. In fact, many display manufacturers use something > 9600. Papenmeier for instance even uses 57600. -- CYa, Mario | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
[BRLTTY] Man page regressions
Hi. I am seeing three (minor) warnings from the Debian lintian package checking system for brltty 3.8 that are all related to BRLTTY manual pages: W: libbrlapi-dev: manpage-has-errors-from-man usr/share/man/man3/brlapi_keys.3.gz 315: warning [p 5, 2.5i]: can't break line W: brltty-x11: binary-without-manpage usr/bin/xbrlapi W: brltty: manpage-has-errors-from-man usr/share/man/man1/vstp.1.gz 117: warning: can't find numbered character 233 -- CYa, Mario ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] Man page regressions
Samuel Thibault <[EMAIL PROTECTED]> writes: > Mario Lang, le Sun 22 Jul 2007 15:27:25 +0200, a écrit : >> W: libbrlapi-dev: manpage-has-errors-from-man >> usr/share/man/man3/brlapi_keys.3.gz 315: warning [p 5, 2.5i]: can't break >> line > > Here is a patch. Great, thanks. Dave, can you apply this please? >> W: brltty: manpage-has-errors-from-man usr/share/man/man1/vstp.1.gz 117: >> warning: can't find numbered character 233 > > That's é of Sébastien. I don't know how to tell groff which character > set is being used. As a workaround, the attached patch2 should be fine. I have no idea how to make groff grok accented chars as well. Maybe someone else? If not, what does sebastien think about this? -- CYa, Mario ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
[BRLTTY] The Baum driver should *NOT* claim a TSI display!
Hi. I remember we've discussed this several months ago already, but now that I am trying brltty 3.8 on one maschine of mine that uses a TSI PowerBraille 80, I have seen this bug again. When I disconnect my TSI and reconnect it later on, it can happen that the Baum driver claims the display in PowerBraille compatibility mode. But this "compatibility" mode is not compatible! So key bindings change, and over all, the user (me!) is confused and has to restart brltty manually. Does the Baum driver really have to claim a 80 cell PowerBraille? AFAIR, the compatibility mode is for the Vario 40 models, that display only has 40 cells by default. Can we perhaps make the baum driver ignore 80 cell TSI displays at least? I have set my braille-driver to auto, but I'd like to keep this setting for several other reasons. -- CYa, Mario ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] The Baum driver should *NOT* claim a TSI display!
Jason White <[EMAIL PROTECTED]> writes: >> Does the Baum driver really have to claim a 80 cell PowerBraille? > > I think this is a bug that should be fixed. Perhaps the Baum driver should > skip checking for TSI and Handytech protocols if the display is connected via > a serial interface and the manufacturer is being auto-detected. One other alternative would be to introduce a braille driver parameter to enable compatibility to other display types in the Baum driver, and set it to off by default. This way, a user that is using the compatibility modes of a Vario could enable this easily in his/her config file, and the other users would be protected from false-positives by default. >> AFAIR, the compatibility mode is for the Vario 40 models, >> that display only has 40 cells by default. Can we perhaps >> make the baum driver ignore 80 cell TSI displays at least? > > I'm sure that 80-cell SuperVario displays have PowerBraille protocol support > as well, so this isn't the right solution. Yes, after I sent the mail I remembered that I was once using a Vario 80 which also had the compatibility modes. -- CYa, Mario | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] The Baum driver should *NOT* claim a TSI display!
Dave Mielke <[EMAIL PROTECTED]> writes: > [quoted lines by Jason White on 2007/08/27 at 10:15 +1000] > >>Am I correct, however, in assuming that the problem only arises with a serial >>interface? > > And, I suspect, with Bluetooth. No, the powerbraille has no bluetooth interface. >>Under USB, the vendor/product ids should be sufficient to distinguish a Baum >>display from a PowerBraille, > > Yes. > >>assuming that later PowerBraille displays have USB interfaces. > > I don't think PowerBrailles are being developed any more. Our thinking, > however, should always allow for such a possibility. > >>If this is right, I would rather the restriction be limited to circumstances >>in which a serial interface is used. If a Baum display is detected via USB >>vendor/product ids, the driver should continue to probe for all supported >>protocols. > > I like this approach. If we're all in agreement then I'll make the change, > which would be that the Baum driver would continue to check for emulation > modes > if USB is bieng used but would only check for the native Baum protocol if > serial or Bluetooth is being used. The Bluetooth part in the above sentence looks like an error. Besides, I am not a Baum Vario user, but if I were and would use my serial interface, I'd not like to loose the ability to use compatibility modes. What about coupling the above approach with a boolean braille driver parameter that would still allow a user to enable probing of compatibility modes even if a serial interface is used? -- CYa, Mario | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] The Baum driver should *NOT* claim a TSI display!
Dave Mielke <[EMAIL PROTECTED]> writes: >>> the Baum driver would continue to check for emulation modes >>> if USB is bieng used but would only check for the native Baum protocol if >>> serial or Bluetooth is being used. >> >>The Bluetooth part in the above sentence looks like an error. > > So you're saying that the driver should always test for the emulation modes if > Bluetooth is being used, i.e. that it should only be careful when serial is > eing used? Yes, because PowerBraille displays only come as serial versions. So the conflict only happens on serial interfaces. >>Besides, I am not a Baum Vario user, but if I were and would use my >>serial interface, I'd not like to loose the ability to use >>compatibility modes. What about coupling the above approach with >>a boolean braille driver parameter that would still allow a user >>to enable probing of compatibility modes even if a serial interface is used? > > Sure. A parameter for this is fine. Do you know if the official Baum word for > those modes is "compatibility", "emulation", or something else? Its "emulation". -- CYa, Mario ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
[BRLTTY] jni.h?
Hi. I have a really strange problem with the Debian package of BRLTTY 3.8 that I fail to understand, maybe someone can shed a little more light on the issue. Its related to the configure stage for the Java bindings. When I build the package on amd64 (64-bit arch) I get working Java bindings. If I build the *same* package on a i386 machine with the same build-dependencies installed, the configure stage fails to find jni.h although it is installed on the system and the Java bindings are subsequently not built. On i386 I have: fzidpc73:/# uname -a Linux fzidpc73 2.6.18-3-686 #1 SMP Sun Dec 10 19:37:06 UTC 2006 i686 GNU/Linux fzidpc73:/# find /usr/lib -name jni.h /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/include/jni.h /usr/lib/gcc/i486-linux-gnu/4.2/include/jni.h and on amd64 I have: x2:/# uname -a Linux x2 2.6.22-1-amd64 #1 SMP Sun Jul 29 13:54:41 UTC 2007 x86_64 GNU/Linux x2:/# find /usr/lib -name jni.h /usr/lib/gcc/x86_64-linux-gnu/4.1/include/jni.h /usr/lib/gcc/x86_64-linux-gnu/4.2/include/jni.h /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/include/jni.h Does anyone have the slightest idea why our configure script does not find jni.h on an i386 host? -- Thanks, Mario | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] jni.h?
Samuel Thibault <[EMAIL PROTECTED]> writes: >> Does anyone have the slightest idea why our configure script >> does not find jni.h on an i386 host? > > Possibly a difference in update-alternatives --display javac ? No, both report Current `best' version is /usr/lib/jvm/java-gcj/bin/javac. Besides, this is autobuilding, so we have no excess software installed like alternative java versions or something like that. You should be able to reproduce this by apt-get update && apt-get build-dep brltty && apt-get source brltty on a Debian sid (unstable) box with i386. brltty-3.8 is in unstable now, but there are no binary packages for i386 yet because of this problem. You can read the build logs here: http://buildd.debian.org/build.php?arch=&pkg=brltty (scroll down to the end of the list and look for the 3.8 builds) Note that the build actually works on amd64, alpha, ia64, mipsel and s390. But fails on arm, i386 and powerpc. I am not really sure about mipsel and s390 atm, but this looks like only 32-bit archs are failing. -- CYa, Mario | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] BRLTTY Debian package has USB autosuspend bug
Jason White <[EMAIL PROTECTED]> writes: > I just discovered today, while installing Debian on a new machine and > upgrading it to the Unstable distribution, that the version of BRLTTY 3.8 in > the Debian Unstable repository has the Autosuspend bug which affects Baum > Supervario (aka Brailliant) and possibly other devices. > > I would suggest upgrading the packaged version to an svn revision that > contains the bug fix. I do not want to unconditionally use subversion. Please convince dave that this bug is worthwhile to release 3.8.1, or, alternatively, let me know a list of revisions that I have to pull to get this fixed. But I am not going to just use whats in svn right now. -- CYa, Mario | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] Problem with speech.c
Christopher Gray <[EMAIL PROTECTED]> writes: > I have 3.8 working now in a terminal window. However, when I go to a > full-screen session, alt+ctrl+f7 in Ubuntu, I get the message "not in text > mode". Is their a cure for this? That depends if you are already logged in to GNOME or not. I havent managed to get GDM accessible with Orca at all yet. But if you are logged in and orca is running, it should actually work with brltty 3.8, at least it works here on my Debian machine. Did the brltty python bindings build and install for you? that is what you need to have Orca talk to brltty 3.8. -- CYa, Mario | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] Problem with speech.c
Christopher Gray <[EMAIL PROTECTED]> writes: > On Fri, 7 Sep 2007, Dave Mielke wrote: > >> Is this perhaps a symptom of starting brltty after the X screen reader? Maybe >> it doesn't try to reconnect. > > I don't think so, but wouldn't say for certain. The reason I am doubting > this > is that the screenreader must be started by hand right now in Ubuntu. On Debian, I can just enable automatic startup of Orca for my specific user that I use for GNOME and everything works just fine after login, no need to manually start it. I guess this should actually work on Ubuntu as well. -- CYa, Mario | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] BRLTTY Debian package has USB autosuspend bug
Dave Mielke <[EMAIL PROTECTED]> writes: > I'm just about ready to release 3.9 now, like in a week or so. Although > things may (probably will) change a bit still, revision 3262 should > be good. Would those who'd like to ensure that their packaging > issues are fixed by the time 3.9 is released, therefore, please test > their packaging with revision 3262 and report any problems to me as > soon as possible. Thanks. I am right now testin r3290 with the packaging for Debian. For some reason, the installation of the BrlAPI manpages (section 3) fails. Did something change regarding the generation of the BrlAPI man pages in the 3.8->3.9 cycle? Could someone please summarize what exactly? I can't seem to pin it down right now. -- Thanks, Mario | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] BRLTTY Debian package has USB autosuspend bug
Mario Lang <[EMAIL PROTECTED]> writes: > I am right now testin r3290 with the packaging for Debian. > For some reason, the installation of the BrlAPI manpages (section 3) fails. > Did something change regarding the generation of the BrlAPI man pages > in the 3.8->3.9 cycle? Could someone please summarize what exactly? > I can't seem to pin it down right now. Follow up to myself: It looks like the man pages do not get installed anymore by default when running make install. Is this intentional? Should I now copy them out of $(build_dir)/Documents/BrlAPIref/man/man3 ? -- CYa, Mario ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
[BRLTTY] TSI: BRLTTY lost display
Hi. I've just had a pretty strange error on my TSI PowerBraille 80 that I've never seen before (with brltty 3.8): Sep 9 13:12:52 x2 brltty[28789]: Unexpected Response: 40 C0 20 A0 62 E0 00 05 51 08 56 31 Sep 9 13:12:52 x2 brltty[28789]: Input byte missing at offset 6. Sep 9 13:12:52 x2 brltty[28789]: Unexpected Response: 2E 30 30 37 37 45 Sep 9 13:12:52 x2 brltty[28789]: Display lost after baud switching It did not reinitialize after some seconds, so I restarted BRLTTY (probably too fast because I now don't know if BRLTTY would have managed to reinitialize the display). Could this have been serial corruption, or something else? Just in case someone can make something of the log entries above. -- CYa, Mario ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] BRLTTY Debian package has USB autosuspend bug
Samuel Thibault <[EMAIL PROTECTED]> writes: > Mario Lang, le Sun 09 Sep 2007 13:30:34 +0200, a écrit : >> Follow up to myself: It looks like the man pages do not get installed >> anymore by default when running make install. Is this intentional? >> Should I now copy them out of $(build_dir)/Documents/BrlAPIref/man/man3 ? > > Note: manpages have never been automatically built when just running > make from the root. You have to run make in the Documents/ directory to > do it (Dave does it before making the release tarball). Yes, I know, and I do run make in the Documents subdirectory in debian/rules. In brltty 3.8, the man pages were installed into usr/share/man upon running make install though, in the current svn version, this apparently has been dropped. -- CYa, Mario | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] BRLTTY Debian package has USB autosuspend bug
Samuel Thibault <[EMAIL PROTECTED]> writes: > /usr/bin/install -c -d /tmp/brltty/debian/brltty/share/man/man3 > > dh_installman -plibbrlapi-dev debian/brltty/usr/share/man/man3/*.3 > > Here is the problem: Dave, it looks like > BRLTTY_PORTABLE_DIRECTORY([mandir], [/usr/share]) > doesn't work as expected: manpages get installed in /share... Ah, yes, thats it, thanks Samuel for catching this one. -- CYa, Mario ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
[BRLTTY] getimeofday and rdate?
Hi. It seems our use of gettimeofday to calculate elapsed time is potentially buggy. When I run "rdate" to resync my computers clock with some internet time server, it can happen that brltty stops to interact with my display for a certain period of time. This only happens when the time gets adjusted some seconds back. It should be fairly easy to reproduce, just set your time in the future and use rdate to correct it again. I havent tried to reproduce it deliberately yet though, it just happened to me two times in the last several weeks. I think this is a real problem, the braille display driver should never hang just because the clock was readjusted! This is with the TSI driver. I dont know (or havent observed it yet) if this also happens with other display drivers. But I am guessing every driver that makes some use of gettimeofday is protentially affected. -- CYa, Mario | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] jni.h?
Samuel Thibault <[EMAIL PROTECTED]> writes: > It looks like you only have libgcj8-dev, provided by gcj-4.2. Are you > maybe compiling with gcc 4.1? In that case I guess gcc 4.1 can't find > gcj-4.2's jni.h. It's possible that you have to explicitely choose > between gcc 4.1 & gcj 4.1 or gcc 4.2 & gcj 4.2. To revisit this thread, it appears I was misled, the configure script of brltty was apparently correct, the build failures were due to some inconsistency in the various arch build daemons since I was uploading the brltty package to unstable just one day after the default compiler was changed from gcc 4.1 to gcc 4.2. In theory, this shouldnt have happend, but something much have been inconsistent since a new upload today revealed that the architectures that were previously failing to build do now indeed build correctly. -- CYa, Mario | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] getimeofday and rdate?
Dave Mielke <[EMAIL PROTECTED]> writes: > [quoted lines by Samuel Thibault on 2007/09/09 at 21:13 +0200] > >>Mario Lang, le Sun 09 Sep 2007 20:51:54 +0200, a écrit : >>> When I run "rdate" to resync my computers clock with some internet >>> time server, it can happen that brltty stops to interact with my display for >>> a certain period of time. >> >>Unfortunately, this is a know problem with gettimeofday() and such >>adjusting programs. For small clock shifts, rdate should use adjtime for >>getting a smooth shift. For bigger shifts, gettimeofday() indeed gets >>shifted. > > What if we make asyncWait() quit if it calculates a negative elapsed time? > That > particular wait will be a bit shorter, but the refresh loop should reset > after > that. Scheduled events like driver restart attempts wouldn't occur for a > while, > but the main loop should be okay. Is that sufficient? I dont fully understand all this yet, but I have a suspicion the hangs in the TSI driver actually come from the TSI driver directly making use of gettimeofday(). I am not sure changing asyncWait() would help aynthing at all with the particular problem I reported above. -- CYa, Mario ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] Disable status cels
Dave Mielke <[EMAIL PROTECTED]> writes: >>Voyager 44 >>I don't like status cels > > The Voyager driver is one which does support what you'd like to do. You need > to > pass in the driver parameter "statuscells=0" (without the quotes). You can do > this via the -B (uppercase) command line option or via the > "braille-parameters" > configuration file directive. THis reminds me, now that 3.8 (and 3.9) are out, could we perhaps try to consolidate the statuscell situation around contiguous displays? I'd really like to be able to configure my Evolution 88 status cells on the left hand side, and would also like to have them available to BrlAPI clients so that I could use the full 88 cell width of my display for GNOME. I was tempted to implement a statusCell parameter for the HandyTech driver in the past several times, but as I understand it, you have a better idea which would solve the issue generically. What is the status on this one? How can I help? -- CYa, Mario | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] Disable status cels
[EMAIL PROTECTED] (Lars Bjørndal) writes: > I'm working at Handy Tech Norway, which is an undependent company, not > tied to Handy Tech in Germany, execpt for selling their products. I'm > using Linux to do all my tasks in office, and I also use an Mod. > Evolution 88. > > I too look forward to see configurabele status cell module at the > left side. Also, I wonder if there exists some plant for implementing > ATC with BRLTTY? If you have a closer look at the HandyTech driver in BRLTTY you will see that basically, ATC is already implemented. We just dont do really much yet with the information. If you have any suggestions, we already have a module Programs/touch.c which encapsulates the touch sensitive information processing, so suggestions could be implemented there. > Also I think it would be fine if we could control some speech > functions from the braille keys, e.g. turning speaking of current > braille line on and off. Some of the speech functionality is already bound to the keypad of the evolution. Do you have any concrete suggestions on what to bind where? -- CYa, Mario ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] debian and brltty
J.Schöber <[EMAIL PROTECTED]> writes: > I used Debian 4.1 Lenny and found it recognised my Papenmeier els out of the > box with no parameters at all! Great! Yes, USB displays should all just work out of the box without any boot parameters. -- CYa, Mario | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
[BRLTTY] "Can't access console"
Hi. I am getting the message from the subject if I launch brltty from the initramfs (very early, before init is launched) when I switch away from console 1 to something else (like 2, or 7). If I restart brltty after runlevel 2 started up completely, I can again switch to consoles other than 1. Additionally, cursor routing does not work either, it immediately answers with the "failed" beep sequence. I guess this is because some device did not exist in my /dev hierarchy while brltty was started first. Is this right? Can we perhaps fix this such that brltty does not need to be restarted? And, what device could I have been missing? Additionally, when I start a brlapi client, it can not connect to brltty if it was started from initramfs, I also have to restart brltty to make brlapi clients work. Maybe this is related to the first issue, or not. -- Any help would be appreciated, Mario | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] "Can't access console"
Dave Mielke <[EMAIL PROTECTED]> writes: >>I guess this is because some device did not exist in my /dev hierarchy >>while brltty was started first. Is this right? > > Yes, it would be. > >>Can we perhaps fix this such that brltty does not need to be restarted? > > That depends on why brltty needs to be restarted. I don't really understand > initramfs, but the problem is probably that brltty is running under a > different > root than later so it has a different /dev than later. Actually, initramfs moves the /dev hierarchy over to the new root directory, so the /dev directory is actually not different, but I guess it could happen that brltty still lives in the old root. > The missing devices probably never get created within the root file > system where brltty is started. > >>And, what device could I have been missing? > > vcsa and tty I just checked, tty exists, but vcsa1 is the only device that exists (because init has not yet started and there are no gettys yet). > Note that brltty does try to create them within the writable directory but it > won't be able to if that directory either doesn't exist or isn't writable. So I could rpbobably also just set -W /dev ? -- CYa, Mario | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] "Can't access console"
Dave Mielke <[EMAIL PROTECTED]> writes:
>>Actually, initramfs moves the /dev hierarchy over to the
>>new root directory, so the /dev directory is actually not different,
>>but I guess it could happen that brltty still lives in the old root.
>
> Yes, the current root directory is part of a process's data. Even a "cd /"
> would still go to the initramfs roto. Perhaps we could add an option to
> specify
> where teh root will move to (relative to the initramfs root) and brltty could
> then keep checking for it until it shows up.
"Shows up" is going to be complicated, because it might as well take some
time until the chroot actually happens and the root fs is fully populated (e.g.,
I use a custom setup at work where the root fs is actually retrieved
with rsync, that can take some time). But yes, that sounds like a plan.
>>I just checked, tty exists, but vcsa1 is the only device
>>that exists (because init has not yet started and there are no gettys yet).
>
> I don't think gettys create those. I think its udev that does.
Yes, but as a side-effect of gettys being started.
> By the way: Does the initramfs stay mounted to the final root file system?
No. The process is roughly this:
* initramfs gets called via /init by the kernel.
* /proc gets mounted (I believe /sys as well, would have to check).
* A series of scripts is executed to setup services like udev, load keymap,
initialize lvm and cryptodisks and so on.
* The real root filesystem is mounted to /root (${rootmnt}).
* The /dev tree created/mounted by udev is moved over from /dev to /root/dev.
* Some cleaning up of the ramfs files is done, I dont rememeber how exactly.
* finally, a special binary does the pivot_root/chroot dance
and finally executes init (the binary is started with exec, so that the
initial initramfs process with PID 1 gets replaced by the
new /sbin/init process from the real root filesystem).
I currently start brltty directly after udev, and before
all other service scripts that might lead to output or
even input (passphrase for crypto, or a failure to mount the real root fs
will actually launch a shell).
Could we perhaps use a special signal to implement this?
We could have some parameter to brltty that tells it what the path
of the new root fs is going to be, and if brltty receives this
signal, it will reopen all its filehandles based on the
new root? We could then just send this signal in
the sysvinit script if we detect that brltty was started
by initramfs...
--
CYa,
Mario
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@mielke.cc
For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] "Can't access console"
Samuel Thibault <[EMAIL PROTECTED]> writes: >> > Note that brltty does try to create them within the writable directory but >> > it >> > won't be able to if that directory either doesn't exist or isn't writable. >> >> So I could rpbobably also just set -W /dev ? > > That should probably work for the console issue, yes. For the record, I tried and it did not help. For now, I will have to restart brltty in the sysvinit script if a early-started process is already running. This is not pretty at all, but it will have to suffice for now. -- CYa, Mario | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] "Can't access console"
Dave Mielke <[EMAIL PROTECTED]> writes: >>"Shows up" is going to be complicated, because it might as well take some >>time until the chroot actually happens and the root fs is fully populated >>(e.g., >>I use a custom setup at work where the root fs is actually retrieved >>with rsync, that can take some time). But yes, that sounds like a plan. > > But brltty is now able to wait for resources. It doesn't need them all to be > available right up front. If enough devices are in the initramfs then it can > get going well enough, and still change to the real root file system later > for > even better functionality. Does the initramfs remain mounted to the real root > file system? No, the ramfs does not stay mounted, its gone after the real /sbin/init starts. >>Could we perhaps use a special signal to implement this? >>We could have some parameter to brltty that tells it what the path >>of the new root fs is going to be, and if brltty receives this >>signal, it will reopen all its filehandles based on the >>new root? We could then just send this signal in >>the sysvinit script if we detect that brltty was started >>by initramfs... > > Do you have a particular signal in mind? Not really, samuel suggests to use SIGHUP. > Is there any convnetional signal for something like that? I dont know of any rules here. I would have used one that is normally not in use (like USR1...) -- CYa, Mario | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
[BRLTTY] Proof of concept code: Filter keyboard keypresses on Linux
Hi.
Virtual console screen readers that wanted to use the
normal keyboard for review functionality always had the
problem on linux that some sort of a non-standardized kernel
patch was needed to get keysniffing to work.
I've been thinking about a method that allows to do this completely
from within userspace without any kernel patching. Now that
I had actually found another use case for this for me personally,
I went ahead and implemented the idea to see if it actually works.
And yes, it does!
The plan is as follows:
* We iterate the input event devices in /dev/input/event* to find
one with criteria that we can use (we can test for bustype, usb
product/vendor ID,
or for the presence of individual keys).
* We then create a "uinput device" to feed keypresses back to the kernel.
* We "grab" the keyboard, i.e., keypresses are no longer sent to the
system, but to us (in userspace) exclusively.
* Whenever we read in a key from our keyboard, we check if
we handle that key, if not, we pass it back to the uinput device,
which in turn will pass it back to the system.
The example code below is written for a Sun type 6 USB
keyboard which I happen to own. This keyboard has some extra keys which
I'd like to use. Most of them are not bound in Linux itself,
but two (MUTE and VOLUMEDOWN) do in fact insert garbage if pressed.
So I had to write this tool to be able to use these keys for
my own purpuses while avoiding them to generate garbage input when used.
The same method could be used in brltty to achieve the following
things we've identified in the past as worthwhile to implement:
* Support braille displays without navigation keys (I've heard
some japanese models are built that way).
* Provide screen review for speech only situations.
* And last but not least, provide better bindings for displays
that do have very few navigation keys (the vario or bookworm comes to mind).
Since keyboards can have many different keys these days (think
USB multimedia keyboards), I guess the best way
to impelement this in brltty is to couple it with
some configuration file parsing that would allow the user
to define which keyboard actions are bound to which brltty commands.
I am open to all input here. As usual, I am not the best code designer,
so some starting help for getting this into brltty core would
be very appreciated? Dave?
P.S.: The following code checks for a specific keyboard.
We will of course want to do something much more generic here,
like test for a keyboard that actually has the keys we'd like to watch out for.
The function has_event() can be used to do this, a call like
has_event(filedescriptor, EV_KEY, KEY_ESC) will return 1 if the keyboard
associated with filedescriptor does have an ESC key...
#include
#include
#include
#include
#include
#include
#include
#include
#include
static int
has_event(int fd, unsigned short type, unsigned short code)
{
#define MAX(a,b) a>b?a:b
const unsigned int len = sizeof(unsigned long)*8;
const unsigned int max = MAX(EV_MAX,
MAX(KEY_MAX,
MAX(REL_MAX,
MAX(ABS_MAX,
MAX(LED_MAX,
MAX(SND_MAX, FF_MAX));
unsigned long bits[(max+len-1)/len];
if (ioctl(fd, EVIOCGBIT(type, max), bits)) {
return (bits[code/len] >> (code%len)) & 1;
}
return 0;
#undef MAX
}
static int
constructKeyboard (char *name, struct input_id *id, unsigned long *keymask)
{
int fd;
if ((fd = open("/dev/input/uinput", O_WRONLY)) > 0) {
struct uinput_user_dev description;
memset(&description, 0, sizeof(description));
strncpy(description.name, name, UINPUT_MAX_NAME_SIZE);
memcpy(&description.id, id, sizeof(description.id));
if (write(fd, &description, sizeof(description)) == sizeof(description)) {
int key;
ioctl(fd, UI_SET_EVBIT, EV_KEY);
ioctl(fd, UI_SET_EVBIT, EV_REP);
for (key=KEY_RESERVED; key<=KEY_MAX; key++) {
if ((keymask[key/(sizeof(unsigned long)*8)] >> (key%(sizeof(unsigned
long)*8)))&1) {
ioctl(fd, UI_SET_KEYBIT, key);
}
}
if (ioctl(fd, UI_DEV_CREATE) != -1) {
return fd;
} else {
perror("ioctl UI_DEV_CREATE");
}
} else {
perror("write (struct uinput_user_dev)");
}
} else {
perror("open /dev/input/uinput");
}
return -1;
}
int
main(int argc, char *argv[])
{
char root[] = "/dev/input";
int rootLength = strlen(root);
int foundKeyboard = 0;
DIR *directory;
if ((directory = opendir(root))) {
struct dirent *entry;
while ((entry = readdir(directory))) {
size_t nameLength = strlen(entry->d_name);
struct stat status;
char path[rootLength + 1 + nameLength + 1];
snprintf(path, sizeof(path), "%s/%s", root, entry->d_name);
if (stat(path, &status) == -1) continue;
if (S_ISCHR(st
Re: [BRLTTY] Proof of concept code: Filter keyboard keypresses on Linux
Samuel Thibault <[EMAIL PROTECTED]> writes: > Andor Demarteau, le Sat 15 Dec 2007 17:28:30 +0100, a écrit : >> nice concept however for yoru special gkeys you could have used >> setkeycoeds and loadkey, at elast for the console. >> on my dell inspiron system some keypresses give off unknown keycode >> messages. >> It refers to setkeycodes to assign them > > Right, but that only permits to assign them usual meanings or simulating > insertion of a string on the current console. That doesn't permit to > increase the volume of the sound board or activate the wireless network > for instance. BTW, Mario, I think your piece of code may be of use for > a lot of people for these examples and not only non-sighted users. Yes, I am aware that this functionality could be useful as a stand alone command line utility, I am still pondering how to design its interface... -- CYa, Mario | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] Filter keyboard keypresses on Linux
Dave Mielke <[EMAIL PROTECTED]> writes: >>some starting help for getting this into brltty core would >>be very appreciated? Dave? > > Sure. What are the recommendations regarding how it should be activated? A > command line option? If so, what should happen on non-Linux platforms? I would recommend it should only get activated if it is needed. There could be an optional configuration file which the user can use to define mappings of key combinations to brltty commands. There could be also a core API for drivers to register mappings (for those displays without buttons and for speech drivers). If there are mappings present, the feature should get "activated", and it could also print a warning on non-linux platforms in that case. I think a command line option does not makes sense. -- CYa, Mario | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] Filter keyboard keypresses on Linux
Dave Mielke <[EMAIL PROTECTED]> writes: >>I think a command line option does not makes sense. > > What about a command line option to specify the configuration file? A command line option + config variable to specify the mapping along the lines of text-table and such would indeed be useful. -- CYa, Mario ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] Filter keyboard keypresses on Linux
Dave Mielke <[EMAIL PROTECTED]> writes: > If we want most of the code to be common within the core then we probably > need > a scheme for portabilizing key representations. Does one already exist or do > we > need to invent it? AIUI, what linux currently uses is derived from the HID standard (Human Interface Devices). So a USB HID device can actually tell the kernel which keys it has. I guess HID is supported on other platforms as well. -- CYa, Mario ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] Filter keyboard keypresses on Linux
Dave Mielke <[EMAIL PROTECTED]> writes: > Can anyone tell me how Speakup intercepts key events? Speakup intercepts all sorts of things by directly patching the kernel. > If we use this scheme how will we be interacting with it? I guess its a bit unpredictable if we are dealing with something that patches into the kernel. It depends on the patch how it interacts with input device clients from user space. > Does it intercept them first, do we, does one scheme disable or > conflict with the otehr, etc? If speakup intercepts on the hardware level (which I guess they do), I guess it will see they keypress anyway. I highly doubt speakup uses the input layer API, they dont like using APIs :-). But, given the current kernel API, this approach (input devices) is the right way to go for a user space application. If we want to intercept keypresses, we really want to do it this way. I'd go as far as claiming if this conflicts with some other patches, the patches are broken, not the input device approach. -- CYa, Mario ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] Filter keyboard keypresses on Linux
Samuel Thibault <[EMAIL PROTECTED]> writes: > Dave Mielke, le Sat 15 Dec 2007 14:56:32 -0500, a écrit : >> Can anyone tell me how Speakup intercepts key events? If we use this scheme >> how >> will we be interacting with it? Does it intercept them first, do we, does >> one >> scheme disable or conflict with the otehr, etc? > > The input layer intercepts keys before Speakup does. THey should nicely > work together (except that we should take care of not stealing hotkeys > from Speakup). Ah, thats great. So we should obviously not define any speakup hotkeys in brltty by default. If someone *wants* to define a conflict in his user configuration, I'd say we have no way of detecting this in advance. -- CYa, Mario | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] Filter keyboard keypresses on Linux
Samuel Thibault <[EMAIL PROTECTED]> writes: > Mario Lang, le Sat 15 Dec 2007 22:29:27 +0100, a écrit : >> Dave Mielke <[EMAIL PROTECTED]> writes: >> >> > If we want most of the code to be common within the core then we probably >> > need >> > a scheme for portabilizing key representations. Does one already exist or >> > do we >> > need to invent it? >> >> AIUI, what linux currently uses is derived from the HID >> standard (Human Interface Devices). > > Mmm, what do you mean by "what linux uses"? Internally, Linux uses > keycodes, which are derived from AT2 scancodes. For USB, it uses the > usb_kbd_keycode[] array for translating from HID to keycodes. I mean the codes defined in input.h, are those keycodes? What standard defines that 138 is HELP? Is this a linux specific thing, or is it defined somewhere else? -- CYa, Mario | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] Filter keyboard keypresses on Linux
Samuel Thibault <[EMAIL PROTECTED]> writes: > Mario Lang, le Sat 15 Dec 2007 22:29:27 +0100, a écrit : >> Dave Mielke <[EMAIL PROTECTED]> writes: >> >> > If we want most of the code to be common within the core then we probably >> > need >> > a scheme for portabilizing key representations. Does one already exist or >> > do we >> > need to invent it? >> >> AIUI, what linux currently uses is derived from the HID >> standard (Human Interface Devices). > > Mmm, what do you mean by "what linux uses"? Internally, Linux uses > keycodes, which are derived from AT2 scancodes. For USB, it uses the > usb_kbd_keycode[] array for translating from HID to keycodes. In /usr/include/linux/input.h I find the following comment: /* * Keys and buttons * * Most of the keys/buttons are modeled after USB HUT 1.12 * (see http://www.usb.org/developers/hidpage). -- CYa, Mario | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] BRLTTY on Debian from Scratch images
Samuel Thibault <[EMAIL PROTECTED]> writes: > Hi, > > Jason White, le Sun 16 Dec 2007 20:22:55 +1100, a écrit : >> Has anybody managed to create a Debian from Scratch image that loads BRLTTY >> automatically when booted? > > Mmmm, this should already be the case with images starting from Etch. > > But if you want to produce images, what you basically need is getting > the sources of debian-installer (apt-get source debian-installer), > and run make in build/. That will fetch udebs from debian mirrors and > build the debian installer. No, Jason was asking about dfsbuild, not d-i. -- CYa, Mario ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] brltty on powerpc
Luke Yelavich <[EMAIL PROTECTED]> writes: > On Sun, Jan 13, 2008 at 10:42:13AM EST, Luke Yelavich wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On Sun, Jan 13, 2008 at 10:30:22AM EST, Dave Mielke wrote: >> > Have you tried with the latest brltty source? >> >> I intend to do just that very shortly. > > Ok, seems like latest SVN works perfectly. Sorry, I missed this, what did you compare? 3.7.2 to SVN or 3.9 to SVN? -- CYa, Mario | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] brltty on powerpc
Samuel Thibault <[EMAIL PROTECTED]> writes: > Mario Lang, le Sun 13 Jan 2008 22:09:52 +0100, a écrit : >> Luke Yelavich <[EMAIL PROTECTED]> writes: >> >> > On Sun, Jan 13, 2008 at 10:42:13AM EST, Luke Yelavich wrote: >> >> On Sun, Jan 13, 2008 at 10:30:22AM EST, Dave Mielke wrote: >> >> > Have you tried with the latest brltty source? >> >> >> >> I intend to do just that very shortly. >> > >> > Ok, seems like latest SVN works perfectly. >> >> Sorry, I missed this, what did you compare? 3.7.2 to SVN or 3.9 to SVN? > > None of 3.7.2, 3.9 or 3.9 with my patch work on ppc. Only Dave's fix in > SVN revision 3407 does work. Does the patch in 3407 apply to 3.9 without causing problems? Should I merge it into 3.9 for Debian? -- CYa, Mario | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] Filter keyboard keypresses on Linux
Dave Mielke <[EMAIL PROTECTED]> writes: > How should we decide which event device is the keyboard? The simplest might > be > someting like selecting the first device which can deliver some well-known > key > event, e.g. space or enter. Any better ideas? Yes, select the keyboard based on the bindings the user configured. I.e., if I have a binding for KEY_HELP, it does not make sense to select a keyboard without that key. > What about systems with more than one keyboard? I think the approach above would eliminate most race conditions with several keyboards. Ideally, brltty could grab all keyboards that have the keys the user wants to use. > Does anyone know what happens if the same event device is opened more than > once, which could happen, for example, if more than one brltty is started? I *think* if the application does not "grab" the keyboard, other apps can still open the device. I never tested what happens if a grabbed keyboard gets opened a second time, but that should be fairly easy to test with a custom piece of C code. I am currently swamped with work, so I could look at this case on the weekend at the earliest. -- CYa, Mario | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
[BRLTTY] OT: Free OMR to braille music translator project
Hi. I recently had a chance to play with Optical Music Recognition software under Windows. There are various products that can scan a page of music and export in MusicXML format. So the hard part (the actual OMR) can be done by the application of choice of the user (there is even a free software OMR program written in Java). Currently, as I see it, there is only one software product to convert notation data to braille music, namely goodfeel from dancing dots. This is windows only software. I just looked at the MusicXML format that these OMR programs export, and it doesn't actually feel too hard to extract meaningful data from that. Notes are already nicely groups by measures, which is what we need for braille music. I am now contemplating to write some little framework for working with musicxml data especially geared towards blind users. If anyone is interested in this topic, please contact me of list. I am trying to figure out if we can create a small team of people working on this. At this stage, people interested in contributing code and design ideas are most needed. Braille music is very complicated, so people with actual experience reading complicated pieces in braille music are also very appreciated. -- CYa, Mario ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
[BRLTTY] Working with braille characters in console mode?
Hi. Does anyone here know if it is at all possible to display braille characters (0X2800-0X28ff) in console mode and have brltty map them correctly to the associated dot combination? I would be sort of happy if it just worked for brltty, if it also worked to have the correct fonts displayed on the screen, that would be an added benefit. Its a real PITA to work with braille output if you have to care about what translation table the user actually uses. Working unicode braille characters would eliminate all the unnecessary complexity when trying to display dot patterns. Any hints? Samuel, I recently saw you got some patch regarding unicode console into linux 2.6.24, does this maybe help in that area? I know it works to display Unicode braille on a webpage and visit that page with Firefox + Orca. However, I'd like to use such functionality in the environment I use on a daily basis, i.e. Emacs in console mode. -- CYa, Mario ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] Working with braille characters in console mode?
Samuel Thibault <[EMAIL PROTECTED]> writes: > Samuel Thibault, le Sat 19 Jan 2008 21:13:46 +, a écrit : >> > have brltty map them correctly to the associated dot combination? >> >> Unfortunately the screen driver model still does't take unicode into >> account and thus brltty will still show question marks for now. > > Maybe we could extend it temporarily without having to revamp everything > right now by just adding a SCR_DOTS request that returns dots, if any? > For 0x28uv, the screen driver would return ' ' for SCR_TEXT and 0xuv for > SCR_DOTS, which the main loop of brltty.c could mix just before the call > to writeWindow. Could you elaborate a litte bit on this? As far as I see, the vcsa device only uses a 16 bit value for each character on the screen to mix attribute and character values. How does an application actually see the character at a certain position is unicode 0x2800? Or did I miss something here? -- CYa, Mario | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] Working with braille characters in console mode?
Samuel Thibault <[EMAIL PROTECTED]> writes: > Samuel Thibault, le Mon 21 Jan 2008 00:20:47 +, a écrit : >> Samuel Thibault, le Sat 19 Jan 2008 23:23:22 +, a écrit : >> > Samuel Thibault, le Sat 19 Jan 2008 21:13:46 +, a écrit : >> > > > have brltty map them correctly to the associated dot combination? >> > > >> > > Unfortunately the screen driver model still does't take unicode into >> > > account and thus brltty will still show question marks for now. >> > >> > Maybe we could extend it temporarily without having to revamp everything >> > right now by just adding a SCR_DOTS request that returns dots, if any? >> > For 0x28uv, the screen driver would return ' ' for SCR_TEXT and 0xuv for >> > SCR_DOTS, which the main loop of brltty.c could mix just before the call >> > to writeWindow. >> >> Here is a patch, tested for the Linux and AtSpi screen drivers. > > Here is a fixed patch (against svn revision 3469) x2:~/src/a11y/brltty% svn up At revision 3469. x2:~/src/a11y/brltty% patch -p0 <~/tmp/patch2 patching file Programs/scr_help.c patching file Programs/scr_base.c patching file Programs/scr_frozen.c patching file Programs/brltty.c patching file Programs/scr.c patching file Programs/scr.h patching file ScreenDrivers/Linux/screen.c Reversed (or previously applied) patch detected! Assume -R? [n] Does not look like this is really against r3469. It seems to conflict with some type width changes that have been applied previously. And yes, I made sure my svn checkout is clean (svn revert -R .). Can you please rediff against the real HEAD and resend? Thanks, keen on trying this out! -- CYa, Mario | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] Working with braille characters in console mode?
Samuel Thibault <[EMAIL PROTECTED]> writes:
> Mario Lang, le Mon 21 Jan 2008 17:49:45 +0100, a écrit :
>> Reversed (or previously applied) patch detected! Assume -R? [n]
>
> Grmbl, it looks like I somehow sent the same patch. Here is hopefully
> the correct one.
Wow! This is extremely cool! I love it, and will immediately start
to use it. For testing purposes, I loaded up
your fonts, configured a UTF-8 locale (also ran unicode_start since
I didnt want to reboot). Emacs, my primary editing environment
offers a function `ucs-insert' which can insert unicode codes.
This is what I use to print 0x28uv chars to my console screen.
There is just one bug I can immediately see, if I enter 2800,
I see a question mark ('?'). All other dot combinations seem to work. Also,
I am not really sure bit I guess cut&paste is also not working. This is
understandable and I can live with it, but ultimately it would of course
be cool to work too.
I do have a test webpage which uses unicode braille to
describe braille music notation briefly in a portable way.
This page apparently at least works with w3m. lynx and links both
seem to have problems printing the unicode braille correctly, but
w3m does it just right, see for yourself: http://delysid.org/music/braille.html
Note that this page works right for everyone (if unicode
is configured), for sighted readers who will see the dots instead of
some weird ascii chars, and for blind people no matter what
translation table they might happen to use. music braille is international
and mostly translation table independent (AFAIK), so in this example, the
benefit of unicode braille shows all the way through.
Dave, any chance of this patch getting accepted? Although it probably
feels like a hack, it is indeed very useful IMO.
--
CYa,
Mario | Debian Developer http://debian.org/>
.''`. | Get my public key via finger [EMAIL PROTECTED]
: :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
`. `'
`- http://delysid.org/> http://www.staff.tugraz.at/mlang/>
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@mielke.cc
For general information, go to: http://mielke.cc/mailman/listinfo/brltty
[BRLTTY] bc640
Hi. I have a Optilec BC640 sitting on my desk for potential driver development. I find the HID interface pretty interesting to play with, so I requested specs from Optilec. They told me Dave is already working on a driver for BRLTTY. Is this true? Any early preview patches to play with and maybe help out? -- Thanks, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] bc640
Dave Mielke <[EMAIL PROTECTED]> writes: >>I have a Optilec BC640 sitting on my desk for >>potential driver development. I find the HID interface >>pretty interesting to play with, so I requested specs from Optilec. >>They told me Dave is already working on a driver for BRLTTY. >>Is this true? Any early preview patches to play with and maybe >>help out? > > I have the specs but haven't yet put any time into it due to lack of access > to > a device as well as the fact that converting brltty to be unicode-based is a > rather large job. A great job, btw, thanks :-) > I also don't yet understand HID interfaces. I at least am as far that I could decode the keypresses pretty easily, but I have no idea how to write to the device yet. Thats why I got interested in specs. At least USB HID seems pretty simple on linux, havent looked at how it works on the bluetooth side yet. I am using linux-specific userspace interfaces though (). > How long do you have it for? Until 13th of February. -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
[BRLTTY] bc640: Some debug info
Hi.
This is as far as I could get without any specs.
Below is a C file that dumps the keypresses to stdout.
Keypresses are delivers pretty strangely, first the "keycode"
arrives, and then the key type. A key type indicator has
the left nibble set to 1110 or to indicate press and release,
and the rightmost nibble indicates the keygroup. 1 seems to be the thumb
keys, 2 are the keys on the left and right side of the display line,
3 are the keys on top of the display, and 4 are the cursor routing keys.
Also attached is a "lsusb -vvv" dump with the device connected.
I still have absolutely no idea how to actually write to the display.
#include
#include
#include
#include
#include
#include
#include
#include
int
main(int argc, char *argv[])
{
int fd;
if ((fd = open("/dev/usb/hiddev0", O_RDONLY)) > 0 ) {
struct hiddev_event e;
while (read(fd, &e, sizeof(e)) == sizeof(e)) {
if (e.value > 0X70) { /* key type indicator */
if ((e.value & 0XF0) == 0X70) {
printf("pressed (type %d)\n", e.value&0X0F);
} else if ((e.value & 0XF0) == 0XF0) {
printf("released (type %d)\n", e.value&0X0F);
}
} else { /* Value indicating which key was pressed */
printf("key %d ", e.value);
}
fflush(stdout);
}
return 0;
} else {
perror("open");
}
exit(EXIT_FAILURE);
}
# lsusb -vvv:
Bus 001 Device 045: ID 0798:0640 Optelec
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0798 Optelec
idProduct 0x0640
bcdDevice0.01
iManufacturer 1 Optelec
iProduct2 Alva BC640
iSerial 6 00A09608574A
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 57
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0 No Subclass
bInterfaceProtocol 0 None
iInterface 3 Alva6 Braille
HID Device Descriptor:
bLength 9
bDescriptorType33
bcdHID 1.00
bCountryCode0 Not supported
bNumDescriptors 1
bDescriptorType34 Report
wDescriptorLength 299
Report Descriptor: (length is 299)
Item(Global): Usage Page, data= [ 0x01 0xff ] 65281
(null)
Item(Local ): Usage, data= [ 0x01 ] 1
(null)
Item(Main ): Collection, data= [ 0x01 ] 1
Application
Item(Global): Report ID, data= [ 0x05 ] 5
Item(Local ): Usage, data= [ 0x07 ] 7
(null)
Item(Global): Logical Maximum, data= [ 0x50 ] 80
Item(Global): Report Size, data= [ 0x08 ] 8
Item(Global): Report Count, data= [ 0x01 ] 1
Item(Main ): Feature, data= [ 0x02 ] 2
Data Variable Absolute No_Wrap Linear
Preferred_State No_Null_Position Non_Volatile
Bitfield
Item(Local ): Usage, data= [ 0x08 ] 8
(null)
Item(Global): Logical Maximum, data= [ 0x01 ] 1
Item(Global): Report Size, data= [ 0x01 ] 1
Item(Global): Report Count, data= [ 0x01 ] 1
Item(Main ): Feature, data= [ 0x02 ] 2
Data Variable Absolute No_Wrap Linear
Preferred_State No_Null_Position Non_Volatile
Bitfield
Item(Global): Report Count, data= [ 0x07 ] 7
Item(Main ): Feature, data= [ 0x01 ] 1
Constant Array Absolute No_Wrap Linear
Preferred_State No_Null_Position Non_Volatile
Bitfield
Item(Local ): Usage, data= [ 0x09 ] 9
(null)
Item(Global): Logical Maximum, data= [ 0x50 ] 80
Item(Global): Report Size, data= [ 0x08 ] 8
Item(Global): Report Count, data= [ 0x01 ] 1
Item(Main ): Feature, data= [ 0x02 ] 2
Data Variable Absolute No_Wrap Linear
Preferred_State No_Null_Position Non_Volatile
Bitfield
Item(Local ): Usage, data= [ 0x0a ] 10
(null)
Re: [BRLTTY] bc640: Some debug info
Andor Demarteau <[EMAIL PROTECTED]> writes: > you will probably not get any specs, I've been bugging optelec here in .nl > for them for some time. Well, Dave already has the specs, so thats not the problem... -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] bc640: Some debug info
Dave Mielke <[EMAIL PROTECTED]> writes: >>Below is a C file that dumps the keypresses to stdout. > > So all you do is open a hiddev and read from it? Yes, for now, thats all that is necessary. The Linux hiddev interface has a bunch of ioctls as well (all defined in linux/hiddev.h). They can be used to get "reports" and do other things, but reading incoming events is as simple as reading from the device. > What's in the event->hid field? -16711674. Dont ask, I have absolutely no idea what this value is supposed to mean. But it seems to stay the same, no matter what key I press. > Do you get any special event(s) when the device is turned off? Turning off and on is a very special topic. Currently, linux seems to have a problem when the device gets turned on, it gets stuck in a connect/disconnect loop for about half a minute, but it seems to settle down then and the hiddev stuff works. I guess this is because this device has a built-in USB storage, but my model has it disabled. So Linux tries to read from the storage, and gets an IO error... I havent figured out yet how to fix this, fortunately the connect/disconnect loop doesnt go on forever, and I was at least able to read from the hiddev. If I turn the device off while my small tool is running, it terminates, so I guess read returns with some sensible value... > Is the device just USB, or does it have serial and/or Bluetooth also? It has USB and bluetooth. AIUI, bluetooth does also support HID, and thats what the device is doing, but I havent played with that yet. USB is a lot easier to handle in early stages of development. >>Keypresses are delivers pretty strangely, first the "keycode" >>arrives, and then the key type. A key type indicator has >>the left nibble set to 1110 or to indicate press and release, > > Is the press really 1110? Your test program makes it look like it's 0111. Right, I was confused. Its 0X7n on press and 0XFn on release. >>and the rightmost nibble indicates the keygroup. 1 seems to be the thumb >>keys, 2 are the keys on the left and right side of the display line, >>3 are the keys on top of the display, and 4 are the cursor routing keys. > > Can you send me a description of the actual key layout along with the code > for > each key? Yes, here we go: Key group 1: The thumb keys. The device has 5 thumb keys, numbers 0 to 4 from left to right. Key group 2: The keys left and right of the display line. The device has 4 of those keys, on the left side of the display 0 and 1, and on the right side 2 and 3. The topmost key is 0 and 2, the bottom one is 1 and 3. Key group 3: These keys are located below the display line, on top of the device. There are 8 of those keys, in the middle you have "cursor keys" with up/down, left/right, and one button in the middle. On the sides, you have two additional keys. Below are the keycodes drawn in the same layout: 4 0 1 2 3 6 7 8 5 Key group 4: Those are the cursor routing keys. They are numbered from 0 to 39, from left to right. This device has a built-in emulated second row of routing keys. If one presses a routing key for half a second, it is still emitted as keygroup 4, but the routing key values are numbered from 128 to 167. One peculiarity that is probably worth mentioning is that this device has the routing keys below the display line, not above as all other devices I have seen so far. >>I still have absolutely no idea how to actually write to the display. > > With the information you've sent about input, I'll see if the specs make > sense > and try to deduce how to do output. That sounds promising, I hope I can be of any help. 7 days to go until I have to give this thing back. -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] bc640: Some debug info
Dave Mielke <[EMAIL PROTECTED]> writes: >>Yes, for now, thats all that is necessary. The Linux hiddev >>interface has a bunch of ioctls as well (all defined in linux/hiddev.h). >>They can be used to get "reports" and do other things, but >>reading incoming events is as simple as reading from the device. > > Do you know what writing to a hiddev is suposed to do? No. I wasn't brave enough to try this yet, since the last display I had for driver hacking (the Trio) died when I wrote a slightly malformed packet to it... > Can you, for example, just write a regular byte stream to it? If so, > then I can tell you how to do a regular Alva write and we can see if > that works. If you tell me which stream, I can try. I havent groked the hiddev interface yet though... > Is /dev/usb/hiddev0 a device in its own right or is it a symlink to somewhere > else? Its a special device file. Quoting Documentation/usb/hiddev.txt from the linux kernel tree: "The hiddev interface is a char interface using the normal USB major, with the minor numbers starting at 96 and finishing at 111." udev automatically creates these device file if a HID compatible USB device gets connected. > If the device is found via searching usbfs, do you know how to then translate > that to the right hiddev device to open or can the usbfs device be opened and > read? hiddev and plain usb devices are on a different layer in the kernel. If we were to use usb devices directly, we would need to impelemtn HID ourselves... There is a libhid which can be used to do HID IO from userspace, but I tried it yesterday but it is buggy. It managed to find the correct device via vendor/product ID, but when trying to retrieve the HID descriptor it fails. This bug seems to be common, since I found some postings about it on the net. So for now, I think we are better of using the linux hiddev interface. >>Key group 1: The thumb keys. The device has 5 thumb keys, numbers 0 to 4 from >>left to right. > > All the same size and equally spaced? Not quite, but mostly. I have the device at home, can examine this in detail today evening. >>Key group 3: These keys are located below the display line, on >>top of the device. There are 8 of those keys, in the middle >>you have "cursor keys" with up/down, left/right, and one button >>in the middle. On the sides, you have two additional keys. >>Below are the keycodes drawn in the same layout: > > Are these keys below the routing keys or above them? Below. > Do there seem to be any limitations regarding which keys can be pressed > together? I havent tried any key combinations yet. -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] Problem with brltty 3.9 on debian testing
Nath <[EMAIL PROTECTED]> writes: > I have installed debian testing on my new Asus Eee pc and I encounter a > problem I never have had before : the braille display turns on sleep > mode every 4 or 5 seconds. when I press a key on the braille display or > on the laptop keyboard the braille display is up again but if I don't > press anything, 4 or 5 seconds after it is in sleep mode again. > My braille display is a Papenmeier braillex el40s (usb), debian testing > kernel version is 2.6.22-3 > I tried with brltty 3.9 from tar.gz instead of the debian package : same > problem. > I searched on differents list archives but didn't find someone having > the same problem. > Perhaps the problem is with this particular kernel or with this > particular kernel in combination with the pm driver ? > Has someone ever encountered a such problem ? I do have a EeePC as well with Debian (lenny) and 2.6.22-3. I use a HandyTech Braille Star 40 and did not observe this problem. Dave: Could this be the same autosuspend problem as the Varios had? -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] Status of powerpc fix in debian netinst
Samuel Thibault <[EMAIL PROTECTED]> writes: >> Just checking again to see whether or not the version of brltty that fixes >> the >> problem with powerpc architecture has yet been implemented in any debian >> installers? > > Not yet :/ I apparently cant find the mail anymore where you told me the revision numbers to pull. AIUI, Java is currently a bit problematic on some arches in Debian, so I will hold off on an upload for a few days still. If you file a bug + patch, the powerpc fix will go in with the next upload. -- Thanks, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
[BRLTTY] Pure python file descriptor watcher code for BrlAPI?
Hi. Orca uses glib to add a callback for when some data arrives at the BrlAPI file descriptor. This is very useful to implement a callback driven system for receiving brlapi keypresses. Does anyone have code for doing this in pure python, without a dependency on glib? -- Thanks, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] Can't compile brltty
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: [...] > ../autogen && ./configure --disable-relocatable-install \ > --disable-table-selection --disable-contracted-braille \ > --enable-beeper-support --disable-midi-support --disable-fm-support \ > --disable-pm-configfile --disable-api --enable-standalone-programs \ ^ [...] > gcc -Wall -g -O2 -I. -I. -I./../Programs -I../Programs -I./.. -I.. > -D_POSIX_C_SOURCE=2 -D_BSD_SOURCE -D_XOPEN_SOURCE=500 > -D_XOPEN_SOURCE_EXTENDED -DHAVE_CONFIG_H -fPIC -c ./brlapi_client.c > ar rc libbrlapi.a brlapi_client.o > ranlib libbrlapi.a > gcc -Wall -static -Wl,-export-dynamic -o tbltest tbltest.o program.o > options.o misc.o io_misc.o queue.o async.o keyboard.o sys_linux.o lock.o > charset.o tbl.o tbl_native.o tbl_gnome.o -ldl -lpthread -lsupc++ -L. > -lbrlapi -lncurses > ../libbrlapi.a(brlapi_client.o): In function `tryHost': > /home/mrkiko/src/brltty/Programs/./brlapi_client.c:468: warning: Using > 'getaddrinfo' in statically linked applications requires at runtime the > shared libraries from the glibc version used for linking > ../libbrlapi.a(brlapi_client.o): In function `brlapi__waitForPacket': > brlapi_client.c:(.text+0x136e): undefined reference to `sem_init' > brlapi_client.c:(.text+0x1387): undefined reference to `sem_wait' > brlapi_client.c:(.text+0x138f): undefined reference to `sem_destroy' > brlapi_client.c:(.text+0x15ba): undefined reference to `sem_post' > brlapi_client.c:(.text+0x16dd): undefined reference to `sem_post' > ../libbrlapi.a(brlapi_client.o): In function `brlapi__openConnection': > brlapi_client.c:(.text+0x289f): undefined reference to > `pthread_mutexattr_init' > brlapi_client.c:(.text+0x28c9): undefined reference to `pthread_mutex_init' > brlapi_client.c:(.text+0x28d8): undefined reference to `pthread_mutex_init' > brlapi_client.c:(.text+0x28e7): undefined reference to `pthread_mutex_init' > brlapi_client.c:(.text+0x28f6): undefined reference to `pthread_mutex_init' > brlapi_client.c:(.text+0x2948): undefined reference to `pthread_mutex_init' > ../libbrlapi.a(brlapi_client.o):brlapi_client.c:(.text+0x29a6): more > undefined references to `pthread_mutex_init' follow > collect2: ld returned 1 exit status So it looks as if --disable-api is broken due to the newly added api-usage in tbltest.c. -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] Can't compile brltty
Samuel Thibault <[EMAIL PROTECTED]> writes: > BTW, Dave, I can see -licuuc -lsupc++ in API_LIBRARIES. These shouldn't > be set, because that makes libbrlapi.so depend on libicuuc.so and > libsupc++.so (and then a packaging dependency) for no reason. BTW, now that I think of it, do we still really need libsupc++? I remember we had to add it back in early 3.0 days since we still used C++ code in the screen drivers. Now that C++ is gone from BRLTTY codebase, do we really need to link to libsupc++? I dont think so. -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
[BRLTTY] Braille input?
Hi. We do have the PASSDOTS command so that drivers can send along braille keyboard keypresses to the core. Some displays do have a braille-keyboard layout by default, and most of our drivers for them do implement something like "input mode" so that the keys can be switched between commands and braille input. The core does currently translate the dots to text and inserts. But what if I want to use the input mode for typing Unicode braille? Can we add a toggle setting so that I can decide if I want PASSDOTS to go through the translation table, or straight to unicode braille? -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] Braille input?
Samuel Thibault <[EMAIL PROTECTED]> writes: > Dave Mielke, le Sat 08 Mar 2008 10:39:10 -0500, a écrit : >> A related issue is that there really should be a way for a braille reader to >> know if a given cell contains a dot pattern or a character. What if, for >> example, the toggle is in the other state than he's expecting it to be? Any >> thoughts? > > Using blinking ? No, please dont make stuff blink by default. We have DESCCHAR for finding out details about a cells content. -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] Braille input?
Dave Mielke <[EMAIL PROTECTED]> writes: >>But what if I want to use the input mode for typing Unicode braille? >> >>Can we add a toggle setting so that I can decide if I want PASSDOTS to >>go through the translation table, or straight to unicode braille? > > Yes, we could certainly add that. The problem with a new toggle, as always, > though, is finding a key binding for it in each relevant driver. While it could be desireable to have a toggle, a preference menu item would be sufficient for a start, drivers that have free key combinations can add the direct toggle later. -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] Braille input?
Dave Mielke <[EMAIL PROTECTED]> writes: >>We have DESCCHAR for finding out details about a cells content. > > Yes, for when the user knows he may need to care. What, though, about > accidents > like when he thinks he's in character mode but is actually entering braille > patterns? How will he catch the fact that he's just sent jibberish rather > than > a well-written memo to his boss? What if we add a very short blip like sound that gets played if braille input does not go through the translation table and is not sent to an API client? -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] Braille input?
Dave Mielke <[EMAIL PROTECTED]> writes: > [quoted lines by Mario Lang on 2008/03/08 at 18:24 +0100] > >>What if we add a very short blip like sound that gets played if braille input >>does not go through the translation table and is not sent to an API client? > > Perhaps. What about if the display had to offer a "shift" key which must be > held down while typing braille patterns? That'd be okay for short braille > sequences but would probably be too inconvenient for long ones. I am leaning more towards "probably to inconvenient", especially if you are trying to type 8-dot braille. > On a related note, do you think the core should also implement navigation > mode for a braille keyboard so that each driver doesn't need to do > it individually? I am not sure this is really feasable, given that some of our current default bindings are pretty optimized on an ergonomic level, and some drivers probably try to keep a minimum level of compatibility to the windows default bindings of that display... What drivers are those, actually. I've been using th plural form, but now that I think of it, I only know about the HandyTech displays, which have a 8-dot braille + 2 space bars layout. What other displays are there, and do they have similarities in how they do navigation mode on the 8 dots? -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] Braille input?
Jason White <[EMAIL PROTECTED]> writes: > In general, I think BRLTTY should eventually move to a model where all of the > bindings of keys/buttons/switches/sensors etc., on the display to BRLTTY > commands are specifiable and configurable outside the drivers, ultimately in a > configuration file. > > The DOS driver supplied with Baum displays used to be able to do this for a > number of their braille display models. For the record, about every DOS driver for any braille display I ever used had something to let the user reconfigure key bindings. This is something vendors usually implemented since their users wanted it. Some used a dedicated bindings configuration file, and some even allowed the user to change bindings interactively. One of our drivers (pm) allows this, but it was generally agreed upon that duplicating this functionality in every driver is wasteful. But a generic mechanism hasn't been devised yet. -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] speech with brltty
Daniel Dalton <[EMAIL PROTECTED]> writes: > On Thu, 21 Feb 2008, Dave Mielke wrote: > >> [quoted lines by Daniel Dalton on 2008/02/21 at 22:19 +1100] >> >>> How do I get brltty talking with speech-dispatcher? >>> >>> And then will it read as I use the arrows? (Like other screenreaders?) >>> >>> What is the command to get this going? >>> I still want braille with my braille note too... >> >> If you mean that you'd like brltty to speak all the time, e.g. as you type >> and >> as you move the cursor, then you need to turn on the AutoSpeak feature. The >> BrailleNote has no key binding for this, but you can still enable it via >> brltty's preferences menu. > > Not sure if I replied earlier. But I turned auto speak on. > So now how do I tell it to use festival or speech dispatcher? You have to select a speech driver, just like you have to select a braille driver for your display. Either edit /etc/brltty.conf, uncommenting the appropriate speech driver, or specify the speech driver at the brltty command line with -s. -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] speech-dispatcher problem
Jason White <[EMAIL PROTECTED]> writes: > On Mon, Mar 17, 2008 at 08:25:16AM +1100, Daniel Dalton wrote: >> >> When I choose speech-dispatcher in brltty.conf and boot it says: >> speech-dispatcher: open failure. >> >> I have no speech. >> >> Anyone know why? I am guessing this is because you are using the Debian package of BRLTTY, and I did not enable speech dispatcher support yet. Patches welcome. (a separate binary package (brltty-speechd?) is going to be needed to minimize the external dependencies of the main brltty package). -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] debian netinst powerpc with brltty: not yet
"Lee Maschmeyer" <[EMAIL PROTECTED]> writes: > The fact that it says "rev unknown" means brltty has not been updated; that > was a bug fixed right after that version was released. No, "rev UNKNOWN" was only fixed in the development branch, there was no new stable release. Because of the lack of stable release updates, we have to manually select patches that need to be applied to 3.9... > I wonder why Debian is so slow getting this updated. Perhaps because Europe > is still on standard time? Oh, are you volunteering to do the work then? -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] Braille tables versus contraction tables.
Dave Mielke <[EMAIL PROTECTED]> writes: > The only significant component of brltty which isn't yet Unicode-based is > the text tables support. What do you people think of getting rid of > them and just using contraction tables (whetther or not we > eventually rename them is another topic)? FWIW, I've always found it a bit strange that the toggle for contraction table usage was 6-dot braille. While it kind of makes sense after some thought, it still feels a bit strange. If we switch all of the normal text tables over to the contraction table system, we could select between contracted and uncontracted braille just by selecting the appropriate table, which does seem a bit more logical than the 6-dot hack. After all, while contraction is historically only used with 6-dot braille, there is nothing technically hindering you to utilize 8-dot braille while still using contraction. > I think there are only two issues we need to pay special attention to. The > first is whether or not horizontal navigation works well enogh. The other is > the way contraction table support currently splits braille windows at word > boundaries. I think if we switch over to the contraction table system for normal text tables, the "one character per cell" idiom has to be preserved, otherwise I totally oppose this change. Its nice to be able to define contractions if you need them, but I think preserving the layout of the characters on-screen is pretty vital to many current users, me included. -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] usb to serial problems
Daniel Dalton <[EMAIL PROTECTED]> writes: > When pluging my braille note into my box with a usb to serial (and an > adapter) (So it will connect since the port on the end of the cable is not > different so won't connect to the BN) I then plug the usb end into my usb > port. > $ sudo dmesg | less > > The last two lines I see are: > > usb 1-1: new full speed USB device using uhci_hcd and address 13 usb 1-1: > configuration #1 chosen from 1 choice pl2303 1-1:1.0: ch341-uart converter > detected usb 1-1: ch341-uart converter now attached to ttyUSB1 > > So I assume it is detected and run: > brltty -b bn -d ttyUSB1 BRLTTY is usually configured to use the usb bus natively by default. Does it help if you explicitly specify serial? Like: brltty -b bn -d serial:ttyUSB1 -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] usb to serial problems
Jason White <[EMAIL PROTECTED]> writes: > If, as I suspect, it is writing to the correct device, there may be a kernel > issue. I've also seen usb-to-serial adaptors that did not fully support the serial port standard -- which do not work with certain serial braille displays (I think it was something related to the RTS/CTS lines, but I might be forgetting things[1]). If you can, try to swap your serial adaptor with another brand, as a last resort. [1] I've been using serial ports back in the old days where BBS (Bulletin-Board-Systems) and FidoNet were still alive and well. I once knew most of the AT command set by heart, and many strange facts about serial lines. Apparently, this knowledge is going down the drain by not being used anymore, probably for the better. Serial ports can be a real PITA, especially when it comes to finding the right cable for a particular task. -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger mlang/[EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] Braille tables versus contraction tables.
Dave Mielke <[EMAIL PROTECTED]> writes: > If we use contraction tables in place of the strictly one-to-one text tables, > what are your collective thoughts on the one major difference that > contraction > table support splits braille windows on word boundaries whereas text table > support doesn't? As stated earlier, I think the "one character per cell" idiom also holds here. If there are characters at position 40, I want to see them. IIUC, splitting at word boundaries would mean (I never really used contracted braille) that if a word doesnt fit at the end of the display, it will not be displayed there. I dont like this, not at all. We could probably invent an opcode to enable/disable this behaviour per table? -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger mlang/[EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
[BRLTTY] doxygen update?
Hi. I am seeing the following warnings from doxygen: /usr/bin/doxygen BrlAPIref.doxy Warning: Tag `USE_WINDOWS_ENCODING' at line 64 of file BrlAPIref.doxy has become obsolete. To avoid this warning please update your configuration file using "doxygen -u" Warning: Tag `MAX_DOT_GRAPH_WIDTH' at line 1124 of file BrlAPIref.doxy has become obsolete. Warning: Tag `MAX_DOT_GRAPH_HEIGHT' at line 1132 of file BrlAPIref.doxy has become obsolete. Should we get these fixed? -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger mlang/[EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
[BRLTTY] strange doxygen manpage generation behaviour
Hi. If I svn export my checkout of brltty, run autogen.sh on my exported version and build brltty and its documentation as usual, I do get a very strange manpage that has the full path of my build directory in it, something like _home_user_some_dir_to_exported-brltty_Programs_.3 which appears to be a "directory listing" of manpages generated by doxygen. This file is very strange and not useful at all, only confusing at best. This might potentially get installed as well. Does anyone with a bit of doxygen insight know how we can turn this off by default? If so, I think we should turn this off. -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger mlang/[EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
[BRLTTY] [Aurelien Jarno] Bug#479754: libbrlapi-dev: /usr/share/man/man3/error.3.gz conflicts with manpages-dev
Hi. Doxygen confuses me, so I am forwarding this bugreport I just got regarding brlapi manpages: Basically, we generate (and install) a manpage named error.3. This conflicts with an already existing manpage on Linux with the same name. Does anyone know how to fix this? The page should probably be called brlapi_error, no? --- Begin Message --- Package: libbrlapi-dev Version: 3.9-7 Severity: serious Preparing to replace libbrlapi-dev 3.9-7 (using .../libbrlapi-dev_3.10~r3710-1_amd64.deb) ... Unpacking replacement libbrlapi-dev ... dpkg: error processing /var/cache/apt/archives/libbrlapi-dev_3.10~r3710-1_amd64.deb (--unpack): trying to overwrite `/usr/share/man/man3/error.3.gz', which is also in package manpages-dev -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libbrlapi-dev depends on: ii libbrlapi0.53.10~r3710-1 braille display access via BRLTTY ii libc6-dev 2.7-10 GNU C Library: Development Librari libbrlapi-dev recommends no packages. -- no debconf information --- End Message --- -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger mlang/[EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] OT: lynx and cookies
Sébastien Hinderer <[EMAIL PROTECTED]> writes: > It is also impossible for me to continue order on Amazon. The site tells > me I should enable cookies in my browser, but they are supposed to be > enabled. I see the same thing here for amazon.de with botz, lynx and lynx-cur. My suspicion is that they changed something on their site which now makes lynx unusable :-(. I have to use firefox for amazon ordering since about 3 months now, which really sucks since it takes me about 3 times as much time to acomplish the same thing I previously did with lynx. -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger mlang/[EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] [Aurelien Jarno] Bug#479754: libbrlapi-dev: /usr/share/man/man3/error.3.gz conflicts with manpages-dev
Samuel Thibault <[EMAIL PROTECTED]> writes: > Mario Lang, le Wed 07 May 2008 13:20:55 +0200, a écrit : >> Doxygen confuses me, so I am forwarding this bugreport I just >> got regarding brlapi manpages: Basically, we generate (and install) >> a manpage named error.3. > > No, the upstream install rules do not install it, they only install > brlapi_* and BRLAPI_* manpages. Excuse me, but where are these install rules to be found? Documents/Makefile doesn't have a install rule, and in the main makefile, I couldnt find anything either. -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger mlang/[EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] OT: lynx and cookies
Sébastien Hinderer <[EMAIL PROTECTED]> writes: >> I have to use firefox >> for amazon ordering since about 3 months now, which really sucks >> since it takes me about 3 times as much time to acomplish the same >> thing I previously did with lynx. > > Hmm! That's an interesting news for me because I didn't realize this was > even possible. Do you use FF with braille only or with Braille and > speech ? I initially used FF with braille and speech, but after I did my first youtube.com experiments, I realized speech doesn't work together with flash movies, so I had to disable it. Dont miss it a lot actually, as a long term brltty user, I am used to not having (useful) speech :-) -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger mlang/[EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] [Aurelien Jarno] Bug#479754: libbrlapi-dev: /usr/share/man/man3/error.3.gz conflicts with manpages-dev
Dave Mielke <[EMAIL PROTECTED]> writes: > [quoted lines by Mario Lang on 2008/05/07 at 15:29 +0200] > >>Excuse me, but where are these install rules to be found? >>Documents/Makefile doesn't have a install rule, and in the main >>makefile, I couldnt find anything either. > > Programs/Makefile: install-api-manpages Something is broken with these documentation installation rules. If I do: mkdir build&&cd build&&../configure&&make&&make install INSTALL_ROOT=/tmp/brlinst in the brltty source directory I do get the following in /tmp/brlinst: x2:/tmp/brlinst% ls bin etc lib share usr x2:/tmp/brlinst% ls bin brltty brltty-config brltty-install vstp xbrlapi x2:/tmp/brlinst% ls share/man/* share/man/man1: brltty.1 share/man/man3: x2:/tmp/brlinst% 1. Note that vtsp and xbrlapi were installed, but their respective manpages were not. 2. The man3 directory is completely empty, why? Should I have run make in the Documents directory manually? If so, why? If doxygen is available, why not build and install the documentation? 3. Note the "share" toplevel directory, which should have been placed under usr/. This might be something related to the way how I use INSTALL_ROOT, but it should still work somehow... -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger mlang/[EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] [Aurelien Jarno] Bug#479754: libbrlapi-dev: /usr/share/man/man3/error.3.gz conflicts with manpages-dev
Dave Mielke <[EMAIL PROTECTED]> writes: >>1. Note that vtsp and xbrlapi were installed, but their respective >> manpages were not. > > Because they haven't been written yet. Thats not quite true: x2:~/src/a11y/brltty% find . -name vstp.1 -o -name xbrlapi.1 ./Documents/xbrlapi.1 ./BrailleDrivers/VisioBraille/vstp.1 >>3. Note the "share" toplevel directory, which should have been placed >> under usr/. This might be something related to the way how I >> use INSTALL_ROOT, but it should still work somehow... > > Yes, it does work correctly if you specify the paths via configure. Ah, so I am supposed to set --install-root= at configure time, not by overriding the Makefile's variable? Thanks, that helped. -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger mlang/[EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] [Aurelien Jarno] Bug#479754: libbrlapi-dev: /usr/share/man/man3/error.3.gz conflicts with manpages-dev
Dave Mielke <[EMAIL PROTECTED]> writes: >>2. The man3 directory is completely empty, why? Should I have >> run make in the Documents directory manually? If so, why? > > Yes, because not all users have doxygen, sgmltools, etc. This was a conscious > decision. Perhaps it's no longer a valid reason, but, at one time, we > certainly > believed it to be valid. So how am I supposed to trigger the man3 installation exactly then? Running "make -C Documents&&make install" in my build directory still does not install them. I end up with an empty man3 directory again. Am I missing something here? -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger mlang/[EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] OT: lynx and cookies
Sébastien Hinderer <[EMAIL PROTECTED]> writes: > Mario Lang (2008/05/07 15:33 +0200): >> I initially used FF with braille and speech, but after I >> did my first youtube.com experiments, I realized speech doesn't >> work together with flash movies, so I had to disable it. > > Okay. By the way: you may be interested by the youtube-dl package which > lets you download a video on youtube and then play it from the > command-line with something like mplayer. Thanks, I am aware of this wonderful tool, and have used it a couple of times in the past. However, if you are searching youtube for something, and need to "look at" several videos until you find the one you were actually looking for, using Firefox and its flash playing capabilities directly is just simpler. >> Dont miss it >> a lot actually, as a long term brltty user, I am used to not having >> (useful) speech :-) > > I wouldn't miss it either, I think. But my last attempts with orca were > rather frustrating, actually. How do you explore the widgets ? Can you > do so just with those brltty comands that are passed to Orca, or do you > need other key bindings ? I am using BRLTTY commands only, with a TSI PowerBraille display... I am getting along with the limited flat review functionalities that Orca currently provides. -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger mlang/[EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
[BRLTTY] [PATCH] Fixes for manpage installation
Hi. * Install xbrlapi.1 and man3/*.3 files if BLD_TOP != SRC_TOP: Index: Programs/Makefile.in === --- Programs/Makefile.in(revision 3714) +++ Programs/Makefile.in(working copy) @@ -518,7 +518,7 @@ $(INSTALL_PROGRAM) $(BLD_TOP)$(DRV_DIR)/*.$(MOD_EXT) $(INSTALL_LIBRARY_DIRECTORY) install-manpages: install-man1-directory - $(INSTALL_DATA) $(BLD_TOP)$(DOC_DIR)/*.1 $(INSTALL_MAN1_DIRECTORY) + $(INSTALL_DATA) $(SRC_TOP)$(DOC_DIR)/*.1 $(BLD_TOP)$(DOC_DIR)/*.1 $(INSTALL_MAN1_DIRECTORY) install-api: $(INSTALL_API_LIBRARIES) install-api-headers install-api-manpages install-api-key $(INSTALL_XBRLAPI) $(INSTALL_API_BINDINGS) @@ -546,7 +546,7 @@ install-api-manpages: install-man3-directory cd $(BLD_TOP)$(DOC_DIR) && $(MAKE) man3 - set -- $(SRC_TOP)$(DOC_DIR)/BrlAPIref/man/man3/brlapi_*.3 && [ -f $$1 ] || exit 0 && \ + set -- $(BLD_TOP)$(DOC_DIR)/BrlAPIref/man/man3/brlapi_*.3 && [ -f $$1 ] || exit 0 && \ $(INSTALL_DATA) $$* $(INSTALL_MAN3_DIRECTORY) install-api-key: -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger mlang/[EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] OT: lynx and cookies
Sébastien Hinderer <[EMAIL PROTECTED]> writes: > Hi, > > Stéphane Doyon (2008/05/07 08:43 -0400): >> It still likes to pause and show it to you, along with >> lots of other useless status messages, makes it a lot slower than it >> could be. > > The -nopause command-line option solves this problem. > Couldn't find its lynx.cfg or lynxrc equivalent, though. If somebody > can, I'm interested. The section "Timeouts" in lynx.cfg might be of interest to you, especially the variables: INFOSECS MESSAGESECS ALERTSECS -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger mlang/[EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] USB and serial/USB converter
Samuel Thibault <[EMAIL PROTECTED]> writes: > There is quite often some confusion between -d usb: and > -d serial:ttyUSB0, and it is not necessarily obvious for the beginners > to understand the difference between both. This is the same on other operating systems. In fact, to configure a USB device on Windows means assigning a more or less random serial port to your converter, and using that COM port in your screen reader. People have to learn the differences everywhere. > Would it be ok to have usb: also try serial:ttyUSB0? It looks like > it could help a lot of people to easily get started with brltty. I have to say, my gut reaction is that I am against such a change. It looks like it needlessly complicates things. There is a very simple way to achieve what you want, setting device to default to "usb:,serial:ttyUSB0". But if you look at it, would you really want to have that as a default? It looks very arbitrary. Besides, most serial drivers still dont support autodetection, so while you might be able reduce the amount of configuration on the users end a little bit, you will also create new problems, since "-b all" will not work with all serial devices... There is a third potential problem with that, some of our natively supported USB braille devices do in fact work like a USB-to-serial adaptor internally, and will be recognized by the Linux kernel. So if you open /dev/ttyUSB0 first, you will end up using the device via the kernel USB-to-serial adaptor driver, not via the native brltty USB implementation. While this probably still works, it looks like another source of potential bugs hard to find. -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger mlang/[EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] USB and serial/USB converter
Samuel Thibault <[EMAIL PROTECTED]> writes: > Mario Lang, le Fri 27 Jun 2008 13:55:24 +0200, a écrit : >> I have to say, my gut reaction is that I am against such a change. > > I have to say that mine was the same. > > The problem is that a few weeks ago I've seen beginners (I mean braille > device beginners, not linux beginners) trying to configure BRLTTY and > failed because of that problem, and it looked like nothing let them > understand the difference between them. As explained earlier, a complete beginner would have even more trouble understanding the configuration required on other platforms. On Windows, you also have to select "COMx" in the device list even though you are using a device connected via the USB bus. > It is possibly just a problem of documentation, maybe the attached > patch would be enough. That is a good idea, I think documenting things can never hurt. The serial autodetection problem is very very old. It hasn't really changed, serial devices will always need a bit of user know how to get up and running. -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger mlang/[EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
[BRLTTY] de.ttb
Hi. While skimming over the new converted de.ttb file in the dev repo, I noticed the following: char \xA7 (12345678) # ⣿ § [SECTION SIGN] char \xB6 (12345678) # ⣿ ¶ [PILCROW SIGN] On first sight, this looks wrong. Given that we have 2^8 possible chars and 2^8 possible dot-patterns, we shouldn't reuse the same dot pattern for two different characters. Any suggestions? -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger mlang/[EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] de.ttb
Dave Mielke <[EMAIL PROTECTED]> writes: >>> On first sight, this looks wrong. Given that we have 2^8 possible >>> chars and 2^8 possible dot-patterns, we shouldn't reuse the >>> same dot pattern for two different characters. > > We actually now have way more than that since the tables have become > unicode-based. I know. I was refering to the first 256 characters only. At least in latin charsets, I think there should be no duplication of dot patterns in the first 256 characters. Not only because it is problematic for those that input via braille keyboard, but also because the ambiguity makes it harder for users to tell what character a certain dot pattern actually represents. > In practice, though, while you can define every single unicode > character, the VGA font in use at any given time can only have up to > 512 characters in it. We're unfortunately limited by that since > Linux doesn't export its unicode image of the screen. The vcs > devices give us font offsets which we then back translate to unicode > characters. I am aware of that. However, I think it might be useful to define a lot more unicode characters since the screen font can be switched pretty easily. Besides, while there is this 512 limitation on linux console, BrlAPI clients like Orca can feed unicode characters to BRLTTY pretty easily without any limitation on 512 characters. If you read a webpage in Firefox with Orca, you might be exposed to a lot of unicode stuff. One example that kind of interests me is the international phonetic alphabet, which is used on Wikipedia sometimes. A mapping for that would be useful... There are other things like certain symbols are kind of duplicated in Unicode. But I cant think of any right now, I'd need to check. -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger mlang/[EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] de.ttb
Jason White <[EMAIL PROTECTED]> writes: > On Sat, Aug 09, 2008 at 01:30:12AM -0400, Dave Mielke wrote: > >> >There are other things like certain symbols are kind of duplicated in >> >Unicode. >> >But I cant think of any right now, I'd need to check. > > As I remember, accented letters are among these: there are so-called > "combining" characters that allow the letter and the accent to be specified > separately, as well as characters that represent the accented letters as > single, combined entities. Well, a separate character would mean that one representation uses more cells than another, right? Normalising that sounds wrong. > One solution to this is to "normalize" the Unicode string before it reaches > the braille translation functions, so that only one representation is ever > used for those characters. If DESCCHAR still returns the original character value, I agree. If not, I disagree... DESCCHAR should always report the actual character... -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger mlang/[EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] de.ttb
Samuel Thibault <[EMAIL PROTECTED]> writes: > Mario Lang, le Sat 09 Aug 2008 07:03:32 +0200, a écrit : >> There are other things like certain >> symbols are kind of duplicated in Unicode. But I cant think >> of any right now, I'd need to check. > > Well, there are all the spacing characters for instance: breakable, > non-breakable, half, thin, etc. Right, thanks. I was actually thinking about the difference spacings... > Then there are the dashes, long, short, etc. A lot of these are > just typography. And I guess there are a few duplicated mathematical symbols as well. -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger mlang/[EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] de.ttb
Samuel Thibault <[EMAIL PROTECTED]> writes: > Hello, > > Mario Lang, le Sat 09 Aug 2008 07:03:32 +0200, a écrit : >> One example that kind of interests me is the international phonetic >> alphabet, which is used on Wikipedia sometimes. A mapping >> for that would be useful... > > I have an experimental one for that. Thats way cool! I think that is one of the first candidates for a subtable included by all tables. Please mail it to the list if possible, thanks. -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger mlang/[EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] de.ttb
Samuel Thibault <[EMAIL PROTECTED]> writes: > Mario Lang, le Sat 09 Aug 2008 10:55:00 +0200, a écrit : >> Jason White <[EMAIL PROTECTED]> writes: >> > On Sat, Aug 09, 2008 at 01:30:12AM -0400, Dave Mielke wrote: >> > >> >> >There are other things like certain symbols are kind of duplicated in >> >> >Unicode. >> >> >But I cant think of any right now, I'd need to check. >> > >> > As I remember, accented letters are among these: there are so-called >> > "combining" characters that allow the letter and the accent to be specified >> > separately, as well as characters that represent the accented letters as >> > single, combined entities. >> >> Well, a separate character would mean that one representation uses more >> cells than another, right? Normalising that sounds wrong. > > Yes and no. The combining character doesn't take room on the screen. > So for instance é (e with acute accent) and é (e + combining acute > accent), although different strings, normalize to the same, and for a > good reason: they appear exactly the same on my screen, occupying only > one column. Oh, that makes good sense then. Thanks for explaining. >> > One solution to this is to "normalize" the Unicode string before it reaches >> > the braille translation functions, so that only one representation is ever >> > used for those characters. >> >> If DESCCHAR still returns the original character value, I agree. If not, >> I disagree... DESCCHAR should always report the actual character... > > I agree with you. The normalization should only happen just before the > output. I.e., in a table, which sort of brings us back to Dave's equivalence idea. -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger mlang/[EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] BrailleNote Over Bluetooth
"Marc Mulcahy" <[EMAIL PROTECTED]> writes: > Sory if this has been discussed here before-- but it appears as though the > BrailleNote is supported, but only over a serial connection, and not via > Bluetooth. Has anyone attempted this? I'm game to try to get it working > with some initial guidance. AFAIK nobody has attempted this yet, maybe because we didn't have a model that supported bluetooth when we developed the driver. How difficult bluetooth support is going to be basically depends on how the display does it. All the bluetooth-supporting models I've worked on so far basically just used the same byte protocol via bluetooth as it already used on the serial port. If thats the case for the BrailleNote you'll basically just have to add the reading/writing functions and the dispatch struct at the top of the file. Additionally, you'll place a new call in brl_construct(). Look at other drivers like the HandyTech driver. Just look for "#ifdef ENABLE_BLUETOOTH_SUPPORT" and things should be pretty clear to you. All code related to bluetooth support in drivers and the core is ifdef'ed so that it can be completely disabled at ./configure time. -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger mlang/[EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] braille doesn't work at all under Ubuntu 8.04.1
Luke Yelavich <[EMAIL PROTECTED]> writes: > On Thu, Sep 04, 2008 at 01:48:26AM EST, Labrador wrote: >> A) it doesn't autodetects my Alva Satellite 544, that's a big problem >> and IMHO an important *regression*, sorry : >> it "auto" was causing some problems, the "serial-usb" now causes 100% of >> problems, what IMHO cannot be seen as a progress in a11y! >> >> B) it also points now for configuring the display **each time I boot up** my >> system: > > If you have a USB display, I.E you are not using a USB to serial adapter, > when selecting the braille option from the CD boot menu, and you get asked > about your display, press exit to continue booting. The configuation prompt > is only for devices that are connected either by serial, USB to serial, and > bluetooth. Luke, this is probably misleading to the ordinary user, because basically all the USB connected braille devices which use a USB to serial adaptor do so internally. So the user usually has no idea that his device uses a USB to serial adaptor, to the user, its just a USB display. This is also how it is advertised by manufacturers or resellers. The fact that a USB to serial adaptor is used internally is a technical detail usually only known by support staff or similar. -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger mlang/[EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
Re: [BRLTTY] having trouble with brltty.conf and how to make Brltty work in cosole and X-windows modes
Scott Berry <[EMAIL PROTECTED]> writes: > I have a Power Braille 80 braille display. I am trying to configure in > the "/etc/brltty.conf" file that I want it too load the braille display > on "/dev/ttyUSB)" because I have a usb to serial converter. But I am > having trouble getting the syntax correct for the device so that it will > load properly. I think in the device directives there should be an > example showing how to actually set up a device like this. There is an example: braille-device serial:ttyS0# First serial device. Just replace ttyS0 by ttyUSB0. A tip regarding the PowerBraille and USB-to-serial adaptors: The PowerBraille uses hardware flow control in a somewhat strange way which can lead to it not working with certain USB-to-serial adaptors. If it doesn't work with your current adaptor, make sure to try a different brand before giving up. > I could not quite understand what the format was. Every device specifier should be prefixed by a bus type (serial, usb, bluetooth), followed by a colon and a string which specifies the device to use. In case of serial, this string just names a device file relative to /dev, in case of usb this string usually specifies a device serial number (in case you have several USB displays connected), and in case of bluetooth, this specifies the bluetooth address of your remote device. > Secondly, I want to use Brltty in both console and X-Windows for Orca. > How would I set this up properly in the "brltty.conf" file? If you are using a Debian package of BRLTTY, Orca should just work out of the box, you dont need to configure anything in /etc/brltty.conf to make BrlAPI clients work. -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/> .''`. | Get my public key via finger mlang/[EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- http://delysid.org/> http://www.staff.tugraz.at/mlang/> ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
