Cheryl Homiak writes:
> I have an old Braille Star 40 here. It works fine with voiceover on my
> Mac
> but I can't bring it up with brltty.
On the Mac, or on Linux?
> I am wondering if a usb driver might be needed such as prolific for
> using it in terminal but that isn't needed for voiceover s
Felix Grützmacher - Handy Tech Elektronik GmbH
writes:
> this might just be me stating the really obvious and making a fool of
> myself, but since the FTDI chip emulates a serial connection through USB and
> the FTDI driver takes care of that, wouldn't it make sense for the device to
> appear as
Felix Grützmacher - Help Tech Elektronik GmbH
writes:
> yes, this is an actual physical Active Braille it's talking to, with
> standard firmware.
I might be lying, but I believe Felix is the first person to test AB/AS
models on Windows. At least I never did, and I don't remember any AB/AS
uwser
Felix Grützmacher - Handy Tech Elektronik GmbH
writes:
> Here is a log excerpt created from running as debug. Seems something went
> wrong.
Basically the exact same log was already submitted by you in July 2016.
Dave analyzed it quite in detail in
<20160712095617.gp26...@beta.private.mielke.cc>
Felix Grützmacher - Help Tech Elektronik GmbH
writes:
> I just tested Easy Braille (ID 0x44) with the following result:
> 2017-04-06@10:17:55.937 USB: testing device: vendor=1FE4 product=0044
> 2017-04-06@10:17:55.937 USB: setup packet: Typ:80 Req:06 Val:0300 Idx:
> Len:00FF
> 2017-04-06@10:
t the URL of the actual
download, that would be highly appreciated for analysis.
> -Ursprüngliche Nachricht-
> Von: BRLTTY [mailto:brltty-boun...@brltty.com] Im Auftrag von Mario Lang
> Gesendet: Donnerstag, 6. April 2017 11:30
> An: 'Informal discussion between users and dev
Samuel Thibault writes:
> The source seems to be downloadable on
>
> https://3rdpartysource.microsoft.com/download/Redistributed%20OSS/5.4/brltty-5.4.zip
>
> It seems to correspond to git 8d46edbf16 + a cherry-pick of 738c1d8b76
> (which was submitted by microsoft at the time).
There is one chan
Dave Mielke writes:
>>and are there some non translated strings in this future release?
>
> Mario should now be able to give you a good answer to this question since
> he's
> updated the German translations.
The messages template is up-to-date. Please change to the Messages
subdirectory, run
kendell clark writes:
> Are there any chances this will make it's way into linux, assuming
> it's not already there?
If you are refering to the possibility of leaving the bluetooth device
address unspecified, yes, that feature has been developed on Linux
first. It has recently been ported to An
Dave Mielke writes:
> One of the pending feature requests is to make freezing the screen be per
> virtual console instead of a global operation. I myself think it's a good
> idea,
> but I thought I'd ask in case anyone can think of a reason why it mightn't be.
I would be totally in favour of
Luke Yelavich writes:
> I am writing to let you all know of my newly launched crowd funding campaign
> to continue to work full time on Linux accessibility development. Please
> spread the word if you are able, it would be much appreciated.
>
> https://patreon.com/lukefoss
This page is totally
Vikash Kesharwani writes:
> Translation is not an issue. I am facing issue with cursor routing. It does
> not work all the time. Can there be any particular reason for this. Is
> cursor routing guaranteed to execute( I am using nano) or there is any
> scenario in which it can fail.
>
> I can see
Hi.
Does anyone know if Raw keycode mode of BrlAPI does still work? Here,
calling brlapi__readKey after brlapi__enterTtyMode with "HandyTech" as
the driver string seems to block forever, while "" as driver string
gives me command keys as expected. I know the number of users of raw
mode might be
Shérab writes:
> Mario Lang (2017/07/23 00:12 +0200):
>> Hi.
>>
>> Does anyone know if Raw keycode mode of BrlAPI does still work? Here,
>> calling brlapi__readKey after brlapi__enterTtyMode with "HandyTech" as
>> the driver string seems to block for
Shérab writes:
> Mario Lang (2017/07/23 11:54 +0200):
>> Oh!!! Thanks for reminding me. Indeed, now it dawns on me that there
>> is this driver-specific translation mechanism... This sort of got lost
>> in the noise (for me) since we have introducted key tables. I gues
Dave Mielke writes:
>>Actually, it seems the HandyTech driver does not support delivering raw
>>key codes yet. It should define the BRL_HAVE_KEY_CODES macro and
>>implement the brl_readKey and brl_keyToCommand methods.
>
> That made sense way back in the days when bindings were hard-coded, but I
Dave Mielke writes:
> [quoted lines by Mario Lang on 2017/07/27 at 09:02 +0200]
>
>>Is there anything that I (with my limited understanding of the core) can
>>do to help in this?
>
> The core - see brl_base:enqueueKeyEvent() - already calls
> api_handleKeyEvent()
Shérab writes:
> Mario Lang (2017/07/27 16:40 +0200):
>> In fact, I know the core doesn't pass the keypresses on because some of
>> the keys result in BRLTTY playing a sound, as if it were trying to read
>> a screen. Maybe the detection logic for brl_keyToComman
Shérab writes:
> Mario Lang (2017/07/27 17:17 +0200):
>> Shérab writes:
>>
>> > Mario Lang (2017/07/27 16:40 +0200):
>> >> In fact, I know the core doesn't pass the keypresses on because some of
>> >> the keys result in BRLTTY playing
Dave Mielke writes:
> [quoted lines by Mario Lang on 2017/07/27 at 21:17 +0200]
>
>>This did the trick:
>>
>> brlapi_range_t Ranges[1];
>> Ranges[0].first = 0;
>> Ranges[0].last = 0X;
>> brlapi__acceptKeyRanges(BrlAPI->handle(), R
Dave Mielke writes:
> [quoted lines by Mario Lang on 2017/07/28 at 09:03 +0200]
>
>>I would even go as far as dropping the exception for BRL_SWITCHVT and
>>similar.
>>After all, the client has just requested raw keycodes, they should know what
>>they are doin
Dave Mielke writes:
> [quoted lines by Mario Lang on 2017/07/28 at 10:14 +0200]
>
>>At least what I am seeing is, that no commands whatsoever arrive if I have
>>selected "raw keycode" mode. Which makes sense, since you probably wouldn't
>>be
>>ab
l...@lamasti.net (Lars Bjørndal) writes:
> On one of my rpis, I have recurring connection problems. The connection can
> work for hours or even days, but suddenly, the connection stops working.
> Typically, the reconnection after a braille display sleep won't work. A
> system reboot doesn't solve
Lars Bjørndal writes:
> On Fri, Aug 11, 2017 at 11:17:38AM +0200, Lars Bjørndal wrote:
>> Hi, Mario!
>>
>> Another note:
>>
>> On the system where I have connection problems, I sometimes experience
>> that a key press on the braille display doesn't do anything. The
>> display, however, moves wh
Dave Mielke writes:
> [quoted lines by Shérab on 2017/08/20 at 11:26 +0200]
>
>>I share Samuel's fear that is will be difficult to design something
>>which is generic enough. What can we do beyond returning the keycodes
>>themselves or brltty commands, as we currently do?
>
> What I suspect we ne
Shérab writes:
> Hi,
>
> Mario Lang (2017/08/24 16:54 +0200):
>> The client would still need to do their own key code
>> handling, which seems fine to me if what is desired is more control.
>
> To make this easier and to warranty as much coherence with the core'
Samuel Thibault writes:
> Hello,
>
> Just to try to summarize a bit what I get from the discussion (I
> couldn't really participate to the thread for lack of time, sorry), what
> could be implemented right away without actual discussion because they
> have clear semantic are:
>
> - make brlapi re
Dave Mielke writes:
> Then, of course, we need to know what the new commands need to be. Perhaps
> someone wouldn't mind looking at Orca and NVDA in order to make a list of
> what
> bindable actions each of those screen readers offers.
I am in the middle of a new cluster installation at work,
Dave Mielke writes:
> [quoted lines by Adrian van Bloois on 2017/11/17 at 22:48 +0100]
>
> You see a lot of Dot7s (which should be ignored or removed) because
> strict BRF is being used.
This is why we have the -6 option of brltty-trtxt.
I usually clean up BRF Braille music by converting to Unic
Vincent LE GOFF writes:
> I'm currently testing a Handytech Active Braille display and I'm now
> trying to use BRLTTY with it. Strangely enough, BRLTTY recognizes the
> display at once and with no particular problem,
Good.
> but key mappings don't work at all as expected. The scrolling button
raphael.poite...@gmail.com (Raphaël POITEVIN) writes:
> Hi!
>
> I didn't tried yet, but I guess the new Raspberry Pi Zero W would get
> your process easier:
> https://www.raspberrypi.org/products/raspberry-pi-zero-w/
Yes, thank you, I know. I am using a pi0w since it was released.
That was a few
Shérab writes:
> I am wondering whether some Unicode characters have a braille
> representation that takes more than one cell in our braille tables.
> There is for instance the case of the horizontal ellipsis (I don't know
> its codepoint anddon't know how to easily find it, sorry). For such a
>
32 matches
Mail list logo
