Re: [BRLTTY] brltty 6.6 under windows not working?
Hi. None of our active devs really use Windows on a regular basis. I wonder if it was a good idea to port to that platform, since that raises expectations on the user side. Simon Eigeldinger writes: > Hi, > > Have redone that with admin privileges. > Forgot about that. :-) > Seems we have the same errors. > attached is the file. > Greetings, > Simon > > > Am 20.05.2024 um 01:18 schrieb Jason J.G. White: >> On 19/5/24 16:02, Simon Eigeldinger wrote: >>> I tried brltty versions 6.3, 6.4, 6.5 and 6.6. >>> >>> Attached is the brltty.log of brltty 6.6. >> There appear to be Windows USB errors. Did you run it with >> administrative privilege? I suspect this isn't the issue, but we >> might as well check. >> I'm not running Windows, so that's the limit of my ability to help. >> ___ >> This message was sent via the BRLTTY mailing list. >> To post a message, send an e-mail to: BRLTTY@brltty.app >> For general information, go to: http://brltty.app/mailman/listinfo/brltty > > > ___ > This message was sent via the BRLTTY mailing list. > To post a message, send an e-mail to: BRLTTY@brltty.app > For general information, go to: http://brltty.app/mailman/listinfo/brltty > -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Braille display unable to type or navigate screen in Ubuntu 22.04
Harry Bell writes: [...] > How can I get my newly set up Ubuntu 24.04 laptop to accept my focus Blue 14 > 5th Gen Braille display as an input device for typing and giving commands to > navigate the screen? > I have installed Ubuntu 24.4 along with Orca and the MATE desktop. I have > run BRLTTY and now my focus Blue 14 5th Gen Braille display shows in Braille > what is on the laptop screen. But when I try typing, nothing happens. Maybe these key bindings help? * set braille keyboard enabled: Space+Dots138 * set braille keyboard disabled: Space+Dots137 > And i have no idea how to navigate the laptop screen., Maybe reading the help page for the Focus 14 will help? http://brltty.app/doc/KeyBindings/brl-fs-focus14.html -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Very beginner Focus 1 70 cell display installation related question
Hammer Attila writes: > A close friend of mine only has 64-bit Windows 11 (maybe 2023 h2). > Do you think it is possible to connect this display with a USB serial > converter via a serial cable? Well, I don't know the hardware, but if it still has a serial port, this is definitely something to try if you want to get it working... -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Very beginner Focus 1 70 cell display installation related question
Hammer Attila writes: > Hello, > > I doed a detailed test (unfortunatelly without success result) to follow > back what versions of BRLTTY worked right previous this old Focus1 modell. Do you have current evidence that the device works at all? In other words, have you successfully initialized it with any other screen reader? When was the last time the device worked for you? -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Affordable refreshable braille display project
"Jason J.G. White" writes: > On 18/3/24 14:49, Sébastien Hinderer wrote: > > I confess that the document felt too long for me to try to study it so I > am just passing the link,, with the hope that it wiill be of interest to > somebody on the list. > > This appeared in social media recently as well. Without commenting on that > particular proposal (or set of proposals), I can say the following. > > There have been many braille display cell technology proposals over the last > several decades, few of which have ever been developed into products, and > details of which can be found by searching a patent database. I've learned > to treat new such proposals with scepticism, at least until there's a > working prototype demonstrated publicly and a plausible plan to manufacture > a device. And rightly so. The graveyard of failed projects is huge. And a few years ago, I think I even happened to cross paths with an outright scam. Besides marketing and a "demo" unit made of wood which only demonstrated the size of the planned device, there was never anything substantial. After some funding was acquired, the team suddenly vanished with no trace. I am deliberately not naming names, but you know who you are if you read this. It has become hard to decide if a "this should be cheaper and simpler" EE-project is worthy of support. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] repairing is necessary
Lars Bjørndal writes: > I've a Raspberry Pi 3B+ connected to a Handy Tech Active Braille braille > display. I use it with BRLTTY only, no graphical UI. After switching > from Raspberry pi OS Bullseye 32-bit to bookworm > 64-bit, I experience from time to time that I have to use bluetoothctl's > remove device command, followed by scan, pair and trust to > reactivate the connections with the display. Is there something I can do > to prevent this from happening so that I have a more stable solution? All I can say is that my experience with the Active Star bluetooth firmware was not very good. Since the products are somewhat similar (Active Braille came first, then Active Star) I am suspecting you might see a firmware problem of the braille device. In general, BRLTTY makes use of the Linux bluetooth stack. Things like pairing are more or less out of our control. Personally, while I've had some pleasant experiences with Bluetooth, all my devices are wired these days. It is just that tad bit more stable, and fewer things to care about/maintain. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Brltty support on OpenBSD
Nicolas Pitre writes: > On Sun, 25 Jun 2023, Dave Mielke wrote: > >> [quoted lines by Crystal Kolipe on 2023/06/25 at 21:17 -0300] >> >> >It's certainly possible to patch OpenBSD to implement a screen >> readout device that would potentially allow brltty to access the >> console independently of any particular login session, just like it >> does on Linux systems. >> >> For the screen driver, we need to know the cursor's coordinates >> (column, row), the screen's dimensions (columns, rows), and the >> characters' Unicode values. Two nice extras would be colour >> information for each character and a way to inject input. I highly doubt upstream would accept such a kernel change. They are very security aware, and poking a hole into the console is likely a trigger for some people. Besides, we have a nice user-space solution these days, we should give it a try before attempting the likely unwanted. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Cursor routing not longer working with kernel 6.3 on Debian testing
Nicolas Pitre writes: > On Sun, 25 Jun 2023, Dave Mielke wrote: > >> [quoted lines by Christian Schoepplein on 2023/06/25 at 20:59 +0200] >> >> >For me it is OK to set >> > >> >dev.tty.legacy_tiocsti=1 >> > >> >in /etc/sysctlconf as a workaround like Rob suggested, thanks Rob for this >> >hint! >> >> I'm wondering if brltty shouldn't just set it automatically? > > The brltty package could install a file in /etc/sysctl.d/ to provide > that config. This way it is more obvious. I like that approach. It is obvious, and easy to change by the user if need be. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] some trouble with handy tech braillestar 80 and the connected keyboard with brltty 6.5
Halim Sahin writes: > I've connected an usb keyboard with a ps/2 converter to my braillestar > 80. > > This way I can use the display with two different machines. I recommend getting an USB switch and connecting the Braille Star and the USB Keyboard to it. These are cheap, and it should work reliably. The BrailleStar 80 is a desktop device, so you are unlikely to carry it around often. A switch should be fine. > It works for me most of the time with following issues: > > 1. some times brltty doesn't reliable get key releases. > In that case typing isn't possible when EG. the left alt or right alt > hangs etc. > In other cases the last pressed key was repeated until pressing a key > again. I think this is a hardware problem, either in the converter or with the PS/2 port of the Star. The driver can only pass on whatever it receives. > 2. selecting the some keytable in brltty.conf doesn't work here. > I've tested EG the desktop keytable. That is likely a limitation of the PASSAT2 support, yes. I guess this could be fixed though. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Strategies for copy/paste
"Dr. Volker Jaenisch" writes:
> Dear Sébastien!
>
> Am 17.01.23 um 21:05 schrieb Sébastien Hinderer:
>
> # highlight-braille-window-location: no {no yes}
> highlight-braille-window-location yes
>
> Just to check twice. This settings indicates for sighted users the location of
> the braille window in the terminal?
>
> I tried this setting, but I see no highligthing in the terminal.
If I remember correctly, this feature only works on a Linux virtual
console directly.
> This may be due to tmux but the real terminal is 700km away and I cannot look
> upon it.
--
CYa,
⡍⠁⠗⠊⠕
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.app
For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Keyboard support HandyTech braille star 80 in brltty
Halim Sahin writes: > I've connected a Keyboard to my braillestar and use brltty 6.3. I am assuing it is a Braille Star 40? > The display is connected via usb or serial (both tested). > > The keyboard works well most of the time but. > > 1. sometimes the pc doesn't get keyreleases reliably > This results in blocked keyboard or hanging arrowkeys etc. Can you relate "sometimes" to something? Maybe high load on the system? Or anything else? > 2. Somethimes the braille display freezes completely so it want a > restart and switching to extern keyboard and back. to work again in > brltty. > > Any ideas? I am assuing you are seeing a hardware problem. I am using more or less your exact setup, on a Raspberry Pi 3, with the original small-size PS/2 keyboard shipped with the Braille Star 40, and I can not really report keyboard issues. I have occasional initialisation issues when turning the display on, but I kind of attribute this to the somewhat strange USB chip in the Raspberry Pi. I have other issues like the rpi not booting while my external USB storage is connected, so I am sort of used to seeing weird things related to USB. However, no apparent keyboard issues here. The scancode passthrough has actually always worked quite reliably for me, since it was implemented around 2003 or so... -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Open bad and brltty.
Dave Mielke writes: >>So i will skip that and look forward to a release of Asahi linux. >>Its still in beta testing. > > What's that? Asahi Linux is an attempt to build a Linux distribution tailored especially to run on current Apple hardware (CPU and GPU). For those long enough in the bussiness, you can think of it as a Yellow Dog Linux reboot. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] FOcus 80, should it work
Jean-Philippe MENGUAL writes: > I am trying a FOcus 80 (freedom scientific) I have just fixed. What exactly do you mean by "I have just fixed". Was the device broken and you did send it in for repair? Or did you do a repair on your own, or perhaps a friend of yours? If the device was repaired, do you have confirmation that the repair actually worked, i.e., did you try the device with another screen reader? Your story below sounds like the device has hardware problems, like sticky keys or perhaps a broken cable? We recently "repaired" an old Vario 40 by replacing the serial cable, which had symptoms somewhat similar to what you describe. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] A Raspberry Pi Zero in a Handy Tech Active Star 40
Raphaël POITEVIN writes: > I recently had an idea. I would try Alpine Linux. Thi distribution is > tinny and maybe faster at boot. > > Have you ever tested? No, I haven't tried Alpine Linux yet. I played a bit with buildroot as a tool to create a image for a rpi. It was fun until I realized that not having gcc available at runtime is a no-go. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Support for braille display alva 570 satellite 80 cells on Android
discapacidad5 writes: > For a long time I have been looking for supports for alba satellite 570 > braille > displays. And apparently there are only drivers for very old 32 bits and there > has been no way to make it work with 64 bits because the drivers are not > available I dont know which operating systems you are talking about, but the ALVA Satellite 570 (and 584) is perfectly supported by BRLTTY. In fact, I use a Satellite 584 since about 2 years. > Digging deeper I found that chromevox uses the brltty library so I > don't understand how Chromevox does braille display can be recognized > and in brltty no Are you saying you failed to get a Satellite working with BRLTTY? On what operating system, Linux? What parameters did you use? > Once I was asking for help to make a brailleBak with USB support to have > precisely this functionality with the old screens since this screen works by > USB > or by serial port but modern computers do not have the serial port anymore, > however brltty has evolved so much that It has a version available now on > Android and perhaps making this briley screen work would be the salvation for > many poor people who barely get these old screens as donations or auctions I fail to understand what you are actually asking for. Perhaps it is USB support for the Satellite 570? I have to admit I never managed to use a Satellite via USB, but that is basically because the USB port of my model is dead. Serial works fine, and USB-to-serial adaptors are cheap. P.S.: I wish you wouldn't associate blindness with keywords like "poor" and "salvation". I don't consider myself poor, but I still use a ALVA Satellite 584 every day. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
[BRLTTY] Emojis and the zen of console
Hi.
Since I was recently (more or less humorously) verbally attacked for
being a linux terminal user ("The stuff you are working with is 30 years
old and all outdated"), and just used DESCCHAR to reveal a smirking face
emoji hidden behind a question mark, I wanted to express my amazement
again that we actually have FULL UNICODE SUPPORT via Linux kernel.
Thanks to everyone involed, especially Nico. vcsu is one of the best
things since sliced bread!!!
--
CYa,
⡍⠁⠗⠊⠕
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.app
For general information, go to: http://brltty.app/mailman/listinfo/brltty
[LAD] [experimental] Simple C++20 JACK Client wrapper
Hi.
std::span<>, std::lerp, std::clamp, just to name some, C++
standardisation has been good to audio devs in recent years.
I always wanted to have a concise modern C++ wrapper class for a JACK client.
Here is my latest (very incomplete) attempt:
https://github.com/mlang/ladxx20
#include
#include
using namespace std;
struct null : lad::processor {
null(): lad::processor("null", 0, 1) {}
void process(audio_buffers audio) override {
for (auto buffer: audio.out) ranges::fill(buffer, 0.0);
}
};
int main() {
null client;
client.start();
this_thread::sleep_for(chrono::seconds(5));
return EXIT_SUCCESS;
}
The idea is to make it as easy as possible to write custom JACK clients.
No callback registration, no port naming, no remembering flags.
Just declare a class and implement a single method.
Buffers are passed to you as spans, so modern for-loop and
all stl algorithms can be used immediately.
This is sort of like a template project for now.
Clone and write your own tool to experiment with DSP.
If you have productive feedback, I am all ears.
I am not looking for language flamewar activity though.
If you are not into C++ for some reason, just go on, there is nothing to see
here...
--
CYa,
⡍⠁⠗⠊⠕
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [BRLTTY] udev rules
Samuel Thibault writes: > Mario Lang, le ven. 13 mai 2022 07:12:54 +0200, a ecrit: >> Samuel Thibault writes: >> >> > As reported on Ubuntu which happens to install brltty by default in its >> > latest release, the udev rules for braille devices with generic USB IDs >> > are hurting people that have hardware that use the same usb-serial chip. >> >> This is a long solved problem. ``Tools/updusbdevs -nogeneric``. > > We'd also need a -genericonly option :) > > (I guess that if we install both the nogeneric udev rules file and the > full udev file, rules for the non-generic devices will get executed > twice, which we don't want) All I was trying to say is that if you run Tools/updusbdevs -nogeneric at build time, the udev rules will be rewritten such that no generic devices are included. This is likely what distributors want. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] udev rules
Samuel Thibault writes: > As reported on Ubuntu which happens to install brltty by default in its > latest release, the udev rules for braille devices with generic USB IDs > are hurting people that have hardware that use the same usb-serial chip. This is a long solved problem. ``Tools/updusbdevs -nogeneric``. mlang@x1:~/Projects/BRLTTY/brltty$ Tools/updusbdevs -h Usage: updusbdevs [-option ...] [scheme:file ...] The following options may be specified: -help show this usage summary and then exit -nogeneric don't include generic USB to serial adapters -quiet decrease verbosity -test don't update the files -verboseincrease verbosity > Dave, could you split the udev rules file in two pieces, one with only > non-generic IDs and one with only generic IDs? That way, distributions > can install brltty by default with the udev rules for non-generic IDs, > and install the udev rules for generic IDs only when requested. I am not arguing against splitting rules by default, just trying to mention that running Tools/updusbdevs as part of the package build process should also do the trick. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
[BRLTTY] Upcoming tmux 3.3 fixes the cursor usage in prompts
Hi. Just a quick heads up to tmux users. As you might have noticed, tmux does not use the cursor in its prompt (C-b :), which screen always did as we would like. Someone must have talked to the tmux maintainers, because the following changelog entry can be found in tmux git: CHANGES FROM 3.2a TO 3.3 ... * Try to leave terminal cursor at the right position even when tmux is drawing its own cursor or selection (such as at the command prompt and in choose mode) for people using screen readers and similar which can make use of it. And indeed, I built the latest git version and cursor behaviour in the tmux prompt is now as we would expect. tmux 3.3 has not been released yet, but it is great to know that the next release will fix this. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Cursor follows display
Dave Mielke writes:
> [quoted lines by Sebastian Humenda on 2022/05/06 at 10:29 +0200]
>
>>For my purposes, it would be even better if it were a mode, i.e. if the mode
>>is enabled, LNDN == KEY_CURSOR_DOWN and LNUP == KEY_CURSOR_UP, and left/right
>>have the described behaviour. If off, everything is like at the moment. The
>>advantage is that I don't need to remember dedicated navigation keys.
>
> Yes, a mode would be best.
>
>>Does this exist and if not, could this be implemented?
>
> No, it doesn't, but it should. Too late for 6.5, though, as I don't
> want, at this point, to risk instability. I'll have a look at it after
> 6.5 has been released.
I have a feeling this could be done right now without any code changes
by using keymap contexts.
context follow Cursor follows display
bind \{Up} KEY_CURSOR_UP
bind \{Down} KEY_CURSOR_DOWN
bind \{Unfollow} CONTEXT+default
context default
bind \{Follow} CONTEXT+follow
bind \{Unfollow} CONTEXT+default
Something similar in a .kti file should do the trick:
assign Up Foo
assign Down Bar
assign Follow K1+K2
assign Unfollow K1+K3
include foollow.kti
--
CYa,
⡍⠁⠗⠊⠕
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.app
For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] [OT] Braille display recommendation
Aura Kelloniemi writes: > Hi, > > On 2022-04-07 at 21:20 +0200, Mario Lang wrote: > > Aura Kelloniemi writes: > > > So if you have any remarks that might be useful for me (including > possible > > > deficiencies of the newest Focus Blue), I'm very interested to read. > > > Since the key layout of Active Braille and Active Star are pretty > > similar, you already ruled out what I would have wnated to suggest. > > I really like my Active Star 40, > > I reconsider the Actie Braille 2021, because it has many advantages. But am I > right that the Active Braille series don't have an SD reader, which means that > I would need to use a proprietary tool to transfer files to/from the internal > storage, if I wish to utilize the note taker. I have no idea about the Active Braille, nor do I use the internal note taker for anything. Its a nice toy, but I prefer Linux on a rasperry pi zero over any sort of internal OS. The android based braille displays might have some interesting features, but the self-written note taker of HelpTech has no future IMO. Frankly, I am not even sure if HelpTech has any future. They have layed off quite some tech people over the years, and have demonstrated a lack of care in their firmware updates (cf. bluetooth stopping to work). But I still like the HelpTech hardware I am using, but I strictly use it as a terminal to work with over appliances. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] [OT] Braille display recommendation
Aura Kelloniemi writes: > Active braille's key layout is also not very ergonomic in my opinion, > as the display has been designed to be used with the ATC mechanism, > which is not very handy in terminal usage scenarios (and probably not > available in BRLTTY). Wrong. BRLTTY implements ATC since the very first days that HandyTech started to use the technology (2006). We updated the autoscroll impelementation a few years ago, which I tested on my Active Star 40. I dont use it very often to be honest, but it does work as expected, and comes quite handy when reading longer texts. > So if you have any remarks that might be useful for me (including possible > deficiencies of the newest Focus Blue), I'm very interested to read. Since the key layout of Active Braille and Active Star are pretty similar, you already ruled out what I would have wnated to suggest. I really like my Active Star 40, mostly due to the design decision to not remove the platform, which makes it easy to place a laptop on top even when sitting in a train. The battery time is very nice, and it can USB charge. And I like the triple action keys. You can also connect a small form factor USB keyboard to it, which is being passed along via Bluetooth HID. This is basically my product idea that I gave to HandyTech around 2000 during a casual chat with management. Paired via bluetooth, you can use the Active Star (and its predecessor Braille Star) as a full wireless braille terminal with keyboard. These days, laptops are everywhere. But back in the day, having a big and loud desktop hidden away in a closet was a pretty nice thing to have. Sitting on the couch with a braille display and keyboard only was a glimpse of the future back then :-) -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] BrlAPI for Haskell
Aura Kelloniemi writes: > Hello, > > On 2022-02-11 at 02:30 +0100, Mario Lang wrote: > > Working on a Haskell binding for BrlAPI. > > Excellent! > > > The following example works: > [--] > > main = withConnection "" ":0" $ \c -> do > > dn <- getDriverName c > > mi <- getModelIdentifier c > > (x, _) <- getDisplaySize c > > withTty c (Just 5) False $ \tty -> do > [--] > > I'd make openConnection and enterTtyMode available too, not jsut the > withSomeHandle-style functions. They are available. In fact, withConnection uses openConnection/closeConnection to do its work. Same for withTty, which uses enterTtyMode/leaveTtyMode. The with-style functions are just a higher level idiom which made the basic example more concise. > > Reading the docs again, I am unsure if I want to mimick the low-level > > API as much as I usually would. I think it would be better to have a > > different type of handle for ttyMode operations. IOW, return some > > handle from enterTtyMode and make writeText and friends use that. > > There are actually a few modes in which a BrlAPI connection can be. I would > implement type classes for the common parts of these modes, and have a > separate handle for each mode (at least basic, tty, raw and tty with raw > keycodes). I think the common operations can still use the initial handle. Typeclasses are neat, but rather questionable without any underlying laws. > In addition I would export the low-level C functions from a separate module, > in case somebody needs them, or the thick binding does not cover 100% of all > possible API use cases. Hmm, good point. The FII is already in a separate module, but I am currently leaning towards not exporting that. > I'm very interested in this project. I try to push my Rust bindings to github > soon, after some clean up. Possibly Rust and Haskell can share some ddesign > decisions. While Rust and Haskell seem to be compared a lot lately, I personally dont see the commonalities. There is laziness, which can be useful but also an unexpected beast. And of course there is purity, which Rust doesn't really have to care about. The safety Rust brings you mostly comes from borrowing. The functional features of Rust are mostly syntactic sugar to me. True, the iterator API and slightly more expression-oriented syntax makes it feel like something one might have seen in more functional languages. But to me, Rust is still a fancy C with better compile-time checking. > I'm especially interested in how are you planning to handle the > parameter API in a typesafe way, including the parameter state change > callbacks. Frankyl, one step at a time. I have no full laid out plan on how to do the complete bindings yet. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
[BRLTTY] BrlAPI for Haskell
Hi. Working on a Haskell binding for BrlAPI. The following example works: module Main where import Control.Monad (void) import BrlAPI main :: IO () main = withConnection "" ":0" $ \c -> do dn <- getDriverName c mi <- getModelIdentifier c (x, _) <- getDisplaySize c withTty c (Just 5) False $ \tty -> do writeText c (show (tty, dn, mi, x)) void $ readKey c Reading the docs again, I am unsure if I want to mimick the low-level API as much as I usually would. I think it would be better to have a different type of handle for ttyMode operations. IOW, return some handle from enterTtyMode and make writeText and friends use that. This would make the sort of error the docs are talking about impossible, and that is pretty much the spirit of type-safe FP. Let me know if you see a big no-no here, otherwise I'll proceed. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Making brltty speak
Sébastien Hinderer writes: > It seems the cleanest solution is to switch from PulseAudo to PipeWire > so I'll have to continue experimenting with that. Whatever you do, switching *away* from PulseAudio is likely the right solution. Even no sound is better then trying to use PulseAudio. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Mac OS Questions
Hi. I personally find it easier to just enable remote login on my Mac and ssh to it from a linux machine. This gives me the same thing you are aiming for, BRLTTY for working with a Mac on the command-line, but I dont have to fiddle with BRLTTY actually running on the Mac. Zachary Kline writes: > Hi all, > > I am a newbie to using Brltty on mac, though have some experience > doing so under Linux. I just wanted to write to see if anyone has any > tips for doing so. I have built a binary, but am currently struggling > a bit with getting bluetooth to work. Obviously, I will need to turn > off VoiceOver, and I gather this will only work in screen. Most of the > time I’m happy with the braille support provided by Apple, I just > figured that something to supplement it would be nice on occasion, > particularly in the terminal. > Any insights from fellow mac people would be appreciated. > Thanks much, > Zack. > > Sent from my iPhone > ___ > This message was sent via the BRLTTY mailing list. > To post a message, send an e-mail to: BRLTTY@brltty.app > For general information, go to: http://brltty.app/mailman/listinfo/brltty -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] [OT] Braille displays with firmware support for Unicode
Aura Kelloniemi writes: > I would like to hear from you, is there any display on the market, which > > 1) has an SD card slot for transfering files > > 2) supports Unicode braille in text files in its firmware text viewer > > 3) supports editing Unicode braille in text files (i.e. typing Unicode braille > patterns instead of regular text) > > 4) allows customizing the braille table used to display text in the firmware > applications. I suspect point 2 and 3 are not implemented by any vendors. > I have taken a look at Focus Blue V, Active braille 2021 and Brailliant BI > X40. I could not find an up to date manual for Active braille 2021, so I > cannot know about that. The others at least do not support custom braille > tables or Unicode braille editing, but I don't know about viewing Unicode > braille. > If there are no devices that support these features, I would like to know, if > there are other people who would be interested. We could possible make a group > request for these features and send it to braille display makers. I have totally given up waiting or requesting features from these companies. Frankly, I think you are way better off implementing your own system based on a real OS and a small computer like a Raspberry or similar. I managed to put a Raspberry Pi 0w into my Active Star a few years ago which would make building your own note-taker pretty simple. But dont wait for these manufacturers to support modern stuff like Unicode Braille. They are stuck in their own world of catering to the common deniminator of users. Supporting experts does not make money, so they dont care. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] TSI braille display protocol
deniz sincar writes:
> what is to and from in the writecells thing?
The TSI protocol supports partial updates. The `from` and `to` parameters
of the writeCells() function pass the start and end of the cells which
should be updated.
> and translateoutputcell.
translateOutputCells() basically translates the bit patterns used by
BRLTTY internally to that which are being used in TSI models. Basically,
some manufacturers use different mappings of bits to dots, so BRLTTY has
a way for drivers to declare a dot mapping according to what
the manufacturer uses. TSI displays actually use the ISO11548-1
mapping, so the bit number directly corresponds to the dot number, and
translateOutputCells() in the TSI driver is effectively a no-op.
> can you explain, do i need to send the dot numbers right afte header?
> and does 1 braille letter with 2 hex numbers?
Lets go through the code in writeCells() and explain what it does:
static const unsigned char header[] = {
0XFF, 0XFF, 0X04, 0X00, 0X99, 0X00
};
This defines the header of a write request. 6 bytes in hexadecimal.
It is basically a constant which will be used later to prepare the
outgoing bytes.
unsigned int length = to - from;
The number of celss which should be written.
unsigned char packet[sizeof(header) + 2 + (length * 2)];
A memory area for the packet to be constructed in. sizeof returns the
numbers of bytes in the header, which in this case is 6. We add 2 to
accomodate for a length and start offset. Every cell needs 2 bytes in
the TSI protocol, so we also need to carve out memory for that,
multiplying the number of cells (length) by 2. For a full update of a
40 cell display, packet would be 6 + 2 + 40*2 = 88 bytes.
unsigned char *byte = packet;
We declare a pointer pointing to the beginning of the memory area we
just defined above. This is going to be used below. This is mostly
specific to C. Some languages would call this an output iterator, I
dont know what your impelemtnation language is, so I cant really
translate the concept into your world.
unsigned int i;
A loop counter for the loop below.
byte = mempcpy(byte, header, sizeof(header));
We copy the (constant) header data to the beginning of the packet.
*byte++ = 2 * length;
We add a byte indicating the length of the packet. See below.
*byte++ = from;
This lets the display know where to start the update. A full update
will always start a 0 (the first cell).
for (i=0; idata->cells[from + i]);
}
Here we actually do the work and put 2 bytes for each cell into the
packet.
The first byte is always 0, and the second byte contains the dot
pattern.
From here on, all you need to do is send the packet off via the serial
port.
So to write all 8 dots raised to the first cell of the display, your
packet should look like this:
0XFF, 0XFF, 0X04, 0X00, 0X99, 0X00, 0X02, 0X00, 0X00, 0XFF
* Byte 1-6 are just the (constant) header
* Byte 7 (0X02) is the number of cells times 2
* Byte 8 (0X00) is the start offset (cell #1)
* Byte 9 (0X00) is the padding (0-byte) for the cell
* Byte 10 (0XFF) contains the actual dot pattern written to cell #1
Hope this helps.
--
CYa,
⡍⠁⠗⠊⠕
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.app
For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] TSI braille display protocol
Dave Mielke writes: > Does iOS no longer support the Baum protocol? > I'd think that some new Baum model, e.g. the VarioUltra, would be a > better fit. Then all you'd need is strict pass through. If the iOS model-detection works the way we assume, yes. The problem here is that how Apple detects models is pretty opaque to us. I guess I will at least have to set my bluetooth name such that iOS believes it is dealing with a display. Simply opening an RFCOMM channel is likely not enough. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] TSI braille display protocol
deniz sincar writes: > Hello. as i don't understand brltty driver code, i want to learn the > tsi braille display driver serial communication protocol in a human > understandable language. I am afraid we dont have exhaustive protocol description in human readable form. Use the source is pretty much the way to go. > for example what is the algorhythm to rase dots 125, 15, 123 and so > on. how to empty the braille display. Both of these questions can pretty easily be answered by reading the function writeCells() from Drivers/Braille/TSI/braille.c It constructs the raw bytes of a write request. A header, some length and start offset bytes, and the actual payload interleaved with NUL bytes. If you are writing your code in C, you could likely take this function almost unchanged and replace the final call to writeBytes with whatever you use to write to the serial port. > i very hardly understand the source code. only what i could do is rase > a very strange dot pattern on the first 2 sells of the display. > i want to learn the protocol of braille output, and the routing keys > because i want to connect it to arduino and output some > information. or maybe i could do some bluetooth emulators, or other > things. > please help me on that, thanks in advance. As said above, we dont have human readable protocol descriptions in most cases. The code is really the best reference you will ever find. Also, I find your question rather vague. It looks like you are planning to do a rewrite of the TSI driver from scratch. Thats fine if you want to do it as an exercise, but I am rather lost on how to help you through the process step by step. Also, is there a particular reason why you cant use BrlAPI for your Bluetooth emulator? I dont see why you should need to reimplement the TSI protocol from scratch. P.S.: I have my own use case for a serial to bluetooth bridge. My goal would be to emulate a display which is supported by iOS, and bridge from a serial display to an iPad. I have never tried to emulate a bluetooth device on a PC, that sounds like a fun project. And it appears it could be useful to others as well. Maybe BRLTTY should have such a tool by default? Does anyone know which iOS supported braille device is most promising/easy to emulate? -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Binding a keyboard to a virtual console?
Samuel Thibault writes: > Hello, > > Mario Lang, le ven. 24 sept. 2021 09:47:58 +0200, a ecrit: >> Does anyone know if there is a way to bind a specific input device to a >> virtual console? > > Apparently, drivers/tty/vt/keyboard.c still doesn't do any input mixing. Looks like userspace is solving this by grabbing an input device. Since we already tunnel all the keyboards through BRLTTY anyway, could we perhaps do key translation for one of them, and insert the resulting keys directly to the VT the lx screen driver is bound to? -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
[BRLTTY] Binding a keyboard to a virtual console?
Hi. Does anyone know if there is a way to bind a specific input device to a virtual console? I am trying to implement a second "seat" in the sense of systemd-logind. Unfortunately, according to the systemd docs, a separate seat would require a graphical session to work. However, I am trying to do this for a virtual console. The lx:VT screen parameter can already be used to bind BRLTTY to a specific console. What is missing is the keyboard. I've done something similar about 20 years ago with a very crude kernel patch. I was running an instance of Emacspeak on a specific terminal, and bound an extra USB keyboard to only emit keypresses to that terminal. Output was synthetic speech from a soundcard, and input came from that second keyboard. In a sense, what I want to do today is very similar, only that output is now Braille. The lx:VT screen parameter is exactly what I need on the braille display side, but the same question as 20 years ago still stands: Can I bind an input device to a specific VT? -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] The braillists forum and an article about reading in braille
Sébastien Hinderer writes: > Are you in a way saying that it would be helpful also for text > application to be able to export their structure somehow, as graphical > ones do? No, actually not. The idea of speech-enabled applications goes a little further. There is the counterargument of "ghetto-applications" lurking in the dark corners, but lets just ignore it for a while so that I can make my point. In most cases, a screen reader has to do guesswork to figure out how to pronounce and present content correctly. Think about dates, times, text with mixed languages, destinguishing between tabs and spaces, mathematical formulas, musical notation, you name it. Widgets did help a little to provide some generic abstractions a screen reader could use as a hint about the actual content and how to interact with it. But UI design isn't stopping, and things presented on-screen are getting increasingly complicated. The new big thing in web design for instance is the HTML5 canvas. Yes, you can now draw arbitrary stuff on a canvas with JavaScript. Wonderful for all sorts of things. But the absolute killer for any sort of classical screen reading. Now the question is, which abstractions or annotations do you create? How do you enrich your abstract widget tree such that the screen reader can make most sense of a hyper-modern application which, say, is dealing with math and music? While the effort to enrich the widgets with more accessibility is definitely worthwhile, certain applications will likely only work if they start to build a screen reader into themselves. The app has all the context required to do a good job. This has been tried in the past, with varying success. Think about IBM Homepage reader, which was really quite cool for the time. But it flopped for the reason given at the beginning of this mail, it was a ghetto-application. Built especially for blind users. However, what T.V. Raman started with Emacspeak doesnt have that issue. Emacspeak is an extension (sort of a plugin) written for a very extensible editor. So the screen reader is built into the application itself. No need to define external interfaces, no need to cramp new stuff into vaguely fitting models. Still much work to actually make things work smoothly, but now you have full access to everything. There is no artificial barrier between the "screen" reader and the application. Everything the application "knows" the "screen" reader can figure out. No need for weird heuristics anymore. You have all the data type and metadata information at your disposal. Of course, speech-enabling every application manually is a insanely huge task which will never get done. But it make sense to look at the landscape of extensible programs and maybe pick a few which might benefit from screen-reading built-in. Emacs is certainly a good example of a success-story for this. > I guess the so-called widgets would be a bit different, may there may > be something to think about there... > > But this wouldperhaps be defeated by the fact that text-mode > applications may be more diverse than graphical ones, in the sense that > graphical ones use one toolkit among a few, which is not so in > text-mode... GUI apps are also quite "diverse" these days. Custom widgets (which lack proper accessibility support) are all over the place. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] The braillists forum and an article about reading in braille
Sébastien Hinderer writes: > Samuel Thibault (2021/08/30 18:56 +0200): >> Sébastien Hinderer, le lun. 30 août 2021 17:54:29 +0200, a ecrit: >> > Regarding the counting feature, I find it very clever! But then I'm >> > wondering, why not ocunting tabs directly? >> >> The screen reader cannot actually "see" the tab characters, it only sees >> spaces. > > Ah yes, this of course makes sense. Sorry. The editor would need to do that. However, note that the fight on tabs vs spaces isn't really being won by any side either. In fact, if I were to aim for primarily speech based coding, I'd look into Emacspeak or similar solutions. You really want structured information when reading code with speech I think. Its not just about identation. You might want to change voices based on syntax highlighting, just to name one example. T.V. Raman really has a point in saying that the artificial boundary between application and screenreader, which is the screen, is a hinderance to good screen reading. If the screen reader had more direct access to the application it is presenting, it could do much more with less heuristics. Which is what Emacspeak demonstrates. There is a learning curve yes, but I guess every sufficiently customizable editor could be used to write a screen reader plugin for. It just appears Emacspeak is about the most complete attempt of that idea. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Intro and a question
Jason White writes: > I've been on this list for a long time, and the GNU screen-based > interface to BRLTTY is rarely mentioned. You may be the first person > to try it in quite a while. The GNU Screen patch method is pretty much the only way to get things going on some of the platforms we try to support. MacOS and OpenBSD come to mind. We wanted to implement bridges to more terminal emulators one day, but that project never really got off the ground. Regarding what Ben wrote, I dont think it is a good idea to trick configure and override the compiler manually. It would be far more fruitful to actually investigate what configure is complaining about. I currently have no working Mac at my disposal, so I can not do this myself. Remote access could help, or someone with a Mac and current OS would need to investigate why building screen apparently fails. Ben, did the patch actually apply without errors? Did you check that? > On 29/5/21 9:02 pm, Ben van Poppel wrote: >> Hi Mario. >> >> Sorry. To put it another way, the only way to successfully run >> configure is by setting CC=/usr/local/bin/gcc-11. The only way to >> build the resulting configuration is setting it back to clang. No >> I’m definitely not running the stock Mac screen binary by mistake, >> because in testing I included the full path. By “runs fine“ I mean >> the resulting screen binary runs and seems otherwise to perform >> normally. >> >> cheers. >> Ben >>> On 30 May 2021, at 12:45 am, Mario Lang wrote: >>> >>> Ben van Poppel writes: >>> >>>> The only strangeness when building Screen itself is that configure >>>> fails with Clang and the build fails with duplicate symbols with >>>> standard GCC. But it seems to build and run fine. >>> This part of the story is confusing to me. You seem to indicate that >>> building screen fails with clang and gcc. But a sentence later you say >>> everything is fine. Could you be a little bit more precise? >>> How (with which compiler) did you actually successfully build screen? >>> Are you sure it did actually build and install, >>> and you aren't using a screen binary already installed on your Mac >>> for some reason? >>> >>> -- AR Mario Lang Phone: +43 316 873 >>> 6897 >>> Graz University of Technology Mobile: +43 664 60 873 6897 >>> IT-Services for research and teaching Email: ml...@tugraz.at >>> Steyrergasse 30/1, 8010 Graz, Austria Please >>> https://useplaintext.email/ >> ___ >> This message was sent via the BRLTTY mailing list. >> To post a message, send an e-mail to: BRLTTY@brltty.app >> For general information, go to: http://brltty.app/mailman/listinfo/brltty > ___ > This message was sent via the BRLTTY mailing list. > To post a message, send an e-mail to: BRLTTY@brltty.app > For general information, go to: http://brltty.app/mailman/listinfo/brltty > -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
Didier Spaier writes: > Le 09/05/2021 à 23:09, Samuel Thibault a écrit : >> Didier Spaier, le dim. 09 mai 2021 23:02:49 +0200, a ecrit: >>> Still, this could be an issue for audiophiles, but they can use jack. >> Speech-based screen reading also requires very low latency to get >> snappy >> feedback. > > OK, then does anyone knows how to measure the latency increase? Latency in RT audio is mostly driven by buffer size. These buffer sizes vary greatly, depending on the software and hardware in use. JACK with a good soundcard can indeed go down to a buffer size of 64 frames or even lower. That makes for a fixed latency of around 2ms, depending on the sample rate. On the ohter end of the spectrum, carelessly written audio programs might go up to buffer sizes of up to 2048. Now latecy is more around 50ms, which is starting to get noticeable. However, I suspect there are several latencies adding up in the case of speech synthesis. It would indeed be worthwhile to investigate if some of these can be reduced. However, I think this would need some automated testing. To come back to your question, can you specify a little more clearly which increase you are refering to? -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] betris -- Tetris for Braille users now online
Raphaël POITEVIN writes: > Grate! Is there a documentation? I dn't understand what to do. It works like any other tetris clone, but sideways. So tetriminos "fall" from right to left. The playing field is 20 dots wide and 10 dots high. Moving the falling tetriminos up/down (with the cursor keys) will also move the viewing area (braille display) so you can explore the remaining field by moving the tetrimino. Pressing the return (enter) key will rotate the current tetrimino. Pressing cursor left will drop the tetrimino. If you manage to fill a full row, it will automatically vanish and the score (in brackets) will increase. Increase score also means increased speed. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
[BRLTTY] betris -- Tetris for Braille users now online
Hi. To avoid building and installing betris altogether, you can now simply do ssh bet...@blind.guru to play the game. This works on Linux as well as on Windows 10. Mac OS X tesers welcome. Happy gaming -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
[elpa] externals/osc 6b6dbb4: Release 0.4
branch: externals/osc commit 6b6dbb4176f45f9ff3a783c816c4556ca2931a22 Author: Mario Lang Commit: Mario Lang Release 0.4 --- osc.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/osc.el b/osc.el index 3c4ef6e..102afae 100644 --- a/osc.el +++ b/osc.el @@ -3,7 +3,7 @@ ;; Copyright (C) 2014-2021 Free Software Foundation, Inc. ;; Author: Mario Lang -;; Version: 0.3 +;; Version: 0.4 ;; Keywords: comm, processes, multimedia ;; This program is free software; you can redistribute it and/or modify
Re: [BRLTTY] Key table definition for Modular Evolution
Lars Bjørndal writes: > I'm using a Handy Tech Modular Evolution 88 braille display. I noticed > that B1+B8+Left/Right didn't activate braille input, as expected. As you say, "as expected". > I can fix this by creating a local table addition, but maybe it should > be set in the defaults for convenience. I am a little torn on this request. On the one hand, you seem to understand why input mode is deliberately not available on the ME, but you still want it to be enabled by default? This seems contradictory. If you know how to enable it locally, I'd suggest you proceed and test the ergonomics for a while. If, after a few weeks of using this, you still think it needs to be available by default, I am happy to follow your advice. As someone who has used a ME88 for roughly 10 years, I personally never wanted to use input mode on it, the keys are just too sturdy to be pretty together repeatedly. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
[elpa] externals/osc 257e602: Fix blob encoding
branch: externals/osc commit 257e602e2d7f0c90662822f5eada2e99285de00d Author: Mario Lang Commit: Mario Lang Fix blob encoding --- osc.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/osc.el b/osc.el index e54b99a..3c4ef6e 100644 --- a/osc.el +++ b/osc.el @@ -54,7 +54,7 @@ (defun osc-blob (vector) (let ((length (length vector))) (concat (osc-int32 length) - vector + (apply #'unibyte-string (append vector nil)) (make-string (% (- 4 (% length 4)) 4) 0 (defun osc-float32 (value)
[elpa] externals/osc dbc5a37: Send signed integers by default
branch: externals/osc commit dbc5a37c3eef0741dde2049927aa8b0f79316923 Author: Mario Lang Commit: Mario Lang Send signed integers by default --- osc.el | 37 - 1 file changed, 28 insertions(+), 9 deletions(-) diff --git a/osc.el b/osc.el index 062f960..e54b99a 100644 --- a/osc.el +++ b/osc.el @@ -81,15 +81,32 @@ (lsh (logand f #XFF00) -8) (logand f #XFF -(defun osc-int32 (value) - (let (bytes) -(dotimes (_ 4) - (push (% value 256) bytes) - (setq value (/ value 256))) -(apply 'unibyte-string bytes))) +(defconst osc-int32-zero (unibyte-string 0 0 0 0)) +(defconst osc-most-negative-signed-int32 (- (ash 1 (1- 32 +(defconst osc-most-positive-signed-int32 (1- (ash 1 (1- 32 +(defconst osc-most-positive-unsigned-int32 (1- (ash 1 32))) + +(defun osc-int32 (integer unsigned) + (cl-check-type integer integer) + (if (zerop integer) + osc-int32-zero +(if unsigned + (unless (and (natnump integer) +(<= integer osc-most-positive-unsigned-int32)) + (signal 'overflow-error (list integer))) + (unless (and (>= integer osc-most-negative-signed-int32) + (<= integer osc-most-positive-signed-int32)) + (signal 'overflow-error (list integer))) + (unless (natnump integer) + (setq integer (+ integer (ash 1 32) +(let (bytes) + (dotimes (_ 4) + (push (logand integer #xFF) bytes) + (setq integer (ash integer -8))) + (apply #'unibyte-string bytes (defconst osc-timetag-now - (concat (osc-int32 0) (osc-int32 1))) + (concat (osc-int32 0 t) (osc-int32 1 t))) (defconst osc-ntp-offset (round @@ -101,9 +118,11 @@ osc-timetag-now (pcase (time-convert time 'list) (`(,high ,low ,usec ,psec) - (concat (osc-int32 (+ (ash high 16) low osc-ntp-offset)) + (concat (osc-int32 (+ (ash high 16) low osc-ntp-offset) + t) (osc-int32 (round (* (+ (* usec 1e-06) (* psec 1e-12)) - (1- (ash 1 32)) + (1- (ash 1 32 + t)) ;;;###autoload (defun osc-make-client (host port)
[elpa] externals/osc 9b288d5: Handle timetags in bundles
branch: externals/osc commit 9b288d571bc5f461263ca8ce48b462a8aac9118d Author: Mario Lang Commit: Mario Lang Handle timetags in bundles --- osc.el | 21 - 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/osc.el b/osc.el index 3c8a38f..062f960 100644 --- a/osc.el +++ b/osc.el @@ -3,7 +3,7 @@ ;; Copyright (C) 2014-2021 Free Software Foundation, Inc. ;; Author: Mario Lang -;; Version: 0.2 +;; Version: 0.3 ;; Keywords: comm, processes, multimedia ;; This program is free software; you can redistribute it and/or modify @@ -228,8 +228,11 @@ string to a vector if embedding in another OSC message is what you want." (1+ (/ f (expt 2.0 52 (defun osc-read-timetag () - (time-add (time-convert (- (osc-read-int32) osc-ntp-offset)) - (time-convert (cons (osc-read-int32) (ash 1 32) + (let ((secs (osc-read-int32)) (frac (osc-read-int32))) +(if (and (zerop secs) (= frac 1)) + nil ; now + (time-add (time-convert (- secs osc-ntp-offset)) + (time-convert (cons frac (ash 1 32))) (defun osc-server-set-handler (server path handler) "Set HANDLER for PATH on SERVER. @@ -268,12 +271,12 @@ the generic handler for SERVER." (?i (osc-read-int32)) (?s (osc-read-string (string-to-list (substring (osc-read-string) 1)) - (forward-char 8) ;skip 64-bit timetag - (while (not (eobp)) - (let ((size (osc-read-int32))) - (osc-filter proc - (buffer-substring - (point) (progn (forward-char size) (point))) + (let ((time (osc-read-timetag))) + (while (not (eobp)) + (let* ((size (osc-read-int32)) +(data (buffer-substring + (point) (progn (forward-char size) (point) + (run-at-time time nil #'osc-filter proc data) ;;;###autoload (defun osc-make-server (host port default-handler)
[elpa] externals/osc 07783f6: Fix osc-send-bundle
branch: externals/osc commit 07783f6677ec5f0623c99580cbfdd21e1d44f099 Author: Mario Lang Commit: Mario Lang Fix osc-send-bundle --- osc.el | 32 +++- 1 file changed, 19 insertions(+), 13 deletions(-) diff --git a/osc.el b/osc.el index f676554..3c8a38f 100644 --- a/osc.el +++ b/osc.el @@ -33,10 +33,6 @@ ;; * `osc-server-set-handler' can be used to change handlers for particular ;; OSC paths on a server process object on the fly. -;; BUGS/TODO: -;; -;; * Timetags are not supported yet. - ;; Usage: ;; ;; Client: (setq my-client (osc-make-client "127.0.0.1" 7770)) @@ -92,11 +88,22 @@ (setq value (/ value 256))) (apply 'unibyte-string bytes))) -(defun osc-timetag (time) - (cl-multiple-value-bind (high low usec psec) (time-convert time 'list) -(concat (osc-int32 (+ 2208988800 (ash high 16) low)) - (osc-int32 (round (* (+ (* usec 1e-06) (* psec 1e-12)) -(1- (ash 1 32 +(defconst osc-timetag-now + (concat (osc-int32 0) (osc-int32 1))) + +(defconst osc-ntp-offset + (round + (float-time (time-subtract (time-convert 0) + (encode-time '(0 0 0 1 1 1900 nil nil t)) + +(defun osc-timetag ( time) + (if (not time) + osc-timetag-now +(pcase (time-convert time 'list) + (`(,high ,low ,usec ,psec) + (concat (osc-int32 (+ (ash high 16) low osc-ntp-offset)) + (osc-int32 (round (* (+ (* usec 1e-06) (* psec 1e-12)) + (1- (ash 1 32)) ;;;###autoload (defun osc-make-client (host port) @@ -141,11 +148,10 @@ string to a vector if embedding in another OSC message is what you want." (process-send-string process (apply #'osc-make-message path args))) (defconst osc-bundle-tag (osc-string "#bundle")) -(defconst osc-timetag-now (concat (osc-int32 0) (osc-int32 1))) (defun osc-make-bundle (time messages) "Make a bundle with timetag TIME and MESSAGES as payload." - (apply #'concat osc-bundle-tag (if time (osc-timetag time) osc-timetag-now) + (apply #'concat osc-bundle-tag (osc-timetag time) (mapcar (lambda (message) (concat (osc-int32 (length message)) message)) messages))) @@ -153,7 +159,7 @@ string to a vector if embedding in another OSC message is what you want." ;;;###autoload (defun osc-send-bundle (process time messages) "Send a bundle to PROCESS with timetag TIME and MESSAGES as payload." - (process-send-string process (apply #'osc-make-bundle path args))) + (process-send-string process (apply #'osc-make-bundle time messages))) (defun osc-read-string () (let ((pos (point)) string) @@ -222,7 +228,7 @@ string to a vector if embedding in another OSC message is what you want." (1+ (/ f (expt 2.0 52 (defun osc-read-timetag () - (time-add (time-convert (- (osc-read-int32) 2208988800)) + (time-add (time-convert (- (osc-read-int32) osc-ntp-offset)) (time-convert (cons (osc-read-int32) (ash 1 32) (defun osc-server-set-handler (server path handler)
[elpa] externals/osc 48d043e: Fix precision of osc-read-timetag
branch: externals/osc commit 48d043e96006e3c0d84848ab506e5590ef8e42a3 Author: Mario Lang Commit: Mario Lang Fix precision of osc-read-timetag --- osc.el | 24 ++-- 1 file changed, 18 insertions(+), 6 deletions(-) diff --git a/osc.el b/osc.el index daa0421..f676554 100644 --- a/osc.el +++ b/osc.el @@ -95,8 +95,7 @@ (defun osc-timetag (time) (cl-multiple-value-bind (high low usec psec) (time-convert time 'list) (concat (osc-int32 (+ 2208988800 (ash high 16) low)) - (osc-int32 (round (* (+ (* usec (expt 10.0 -6)) - (* psec (expt 10.0 -12))) + (osc-int32 (round (* (+ (* usec 1e-06) (* psec 1e-12)) (1- (ash 1 32 ;;;###autoload @@ -141,6 +140,21 @@ string to a vector if embedding in another OSC message is what you want." "Send an OSC message from PROCESS to the specified PATH with ARGS." (process-send-string process (apply #'osc-make-message path args))) +(defconst osc-bundle-tag (osc-string "#bundle")) +(defconst osc-timetag-now (concat (osc-int32 0) (osc-int32 1))) + +(defun osc-make-bundle (time messages) + "Make a bundle with timetag TIME and MESSAGES as payload." + (apply #'concat osc-bundle-tag (if time (osc-timetag time) osc-timetag-now) +(mapcar (lambda (message) + (concat (osc-int32 (length message)) message)) +messages))) + +;;;###autoload +(defun osc-send-bundle (process time messages) + "Send a bundle to PROCESS with timetag TIME and MESSAGES as payload." + (process-send-string process (apply #'osc-make-bundle path args))) + (defun osc-read-string () (let ((pos (point)) string) (while (not (= (following-char) 0)) (forward-char 1)) @@ -208,10 +222,8 @@ string to a vector if embedding in another OSC message is what you want." (1+ (/ f (expt 2.0 52 (defun osc-read-timetag () - (let ((secs (osc-read-int32)) - (frac (osc-read-int32))) -(time-convert (+ (- secs 2208988800) -(/ (float frac) (1- (ash 1 32))) + (time-add (time-convert (- (osc-read-int32) 2208988800)) + (time-convert (cons (osc-read-int32) (ash 1 32) (defun osc-server-set-handler (server path handler) "Set HANDLER for PATH on SERVER.
[elpa] externals/osc c916424: New function `osc-make-message'
branch: externals/osc commit c91642422eaea3cf4e7447e89a98dbe84f47e9a5 Author: Mario Lang Commit: Mario Lang New function `osc-make-message' --- osc.el | 33 + 1 file changed, 25 insertions(+), 8 deletions(-) diff --git a/osc.el b/osc.el index 5a6a33d..daa0421 100644 --- a/osc.el +++ b/osc.el @@ -92,6 +92,13 @@ (setq value (/ value 256))) (apply 'unibyte-string bytes))) +(defun osc-timetag (time) + (cl-multiple-value-bind (high low usec psec) (time-convert time 'list) +(concat (osc-int32 (+ 2208988800 (ash high 16) low)) + (osc-int32 (round (* (+ (* usec (expt 10.0 -6)) + (* psec (expt 10.0 -12))) +(1- (ash 1 32 + ;;;###autoload (defun osc-make-client (host port) "Create an OSC client process which talks to HOST and PORT." @@ -102,13 +109,12 @@ :service port :type 'datagram)) -;;;###autoload -(defun osc-send-message (client path args) - "Send an OSC message from CLIENT to the specified PATH with ARGS." - (process-send-string - client - (apply -'concat +(defun osc-make-message (path args) + "Make a OSC message with specified PATh and ARGS. +A unibyte string is returned. Use `vconcat' to convert that unibyte +string to a vector if embedding in another OSC message is what you want." + (apply + 'concat (osc-string path) (osc-string (apply @@ -128,7 +134,12 @@ ((integerp arg) (osc-int32 arg)) ((stringp arg) (osc-string arg)) ((vectorp arg) (osc-blob arg - args + args))) + +;;;###autoload +(defun osc-send-message (process path args) + "Send an OSC message from PROCESS to the specified PATH with ARGS." + (process-send-string process (apply #'osc-make-message path args))) (defun osc-read-string () (let ((pos (point)) string) @@ -196,6 +207,12 @@ (expt 2.0 (- e 1023)) (1+ (/ f (expt 2.0 52 +(defun osc-read-timetag () + (let ((secs (osc-read-int32)) + (frac (osc-read-int32))) +(time-convert (+ (- secs 2208988800) +(/ (float frac) (1- (ash 1 32))) + (defun osc-server-set-handler (server path handler) "Set HANDLER for PATH on SERVER. IF HANDLER is nil, remove previously defined handler and fallback to
[elpa] externals/osc ef72809: Set binary coding for servers
branch: externals/osc commit ef72809f3d425e502a379790863bdb4a46ab4797 Author: Mario Lang Commit: Mario Lang Set binary coding for servers --- osc.el | 1 + 1 file changed, 1 insertion(+) diff --git a/osc.el b/osc.el index 8be30ef..5a6a33d 100644 --- a/osc.el +++ b/osc.el @@ -249,6 +249,7 @@ fine grained control. A process object is returned which can be dicarded with `delete-process'." (make-network-process :name "OSCserver" + :coding 'binary :filter #'osc-filter :host host :service port
[elpa] externals/osc 41c6577: Support for receiving double precision (float64) values
branch: externals/osc commit 41c65773a75014cd32da5cf2072e6b563002bbff Author: Mario Lang Commit: Mario Lang Support for receiving double precision (float64) values --- osc.el | 26 +- 1 file changed, 25 insertions(+), 1 deletion(-) diff --git a/osc.el b/osc.el index 28a1a5c..8be30ef 100644 --- a/osc.el +++ b/osc.el @@ -1,6 +1,6 @@ ;;; osc.el --- Open Sound Control protocol library -*- lexical-binding:t -*- -;; Copyright (C) 2014-2020 Free Software Foundation, Inc. +;; Copyright (C) 2014-2021 Free Software Foundation, Inc. ;; Author: Mario Lang ;; Version: 0.2 @@ -173,6 +173,29 @@ (expt 2.0 (- e 127)) (1+ (/ f (expt 2.0 23 +(defun osc-read-float64 () + (let ((s (lsh (logand (following-char) #X80) -7)) + (e (+ (lsh (logand (following-char) #X7F) 4) + (lsh (logand (progn (forward-char) (following-char)) #XF0) -4))) + (f (+ (lsh (logand (following-char) #X0F) 48) + (lsh (progn (forward-char) (following-char)) 40) + (lsh (progn (forward-char) (following-char)) 32) + (lsh (progn (forward-char) (following-char)) 24) + (lsh (progn (forward-char) (following-char)) 16) + (lsh (progn (forward-char) (following-char)) 8) + (prog1 (progn (forward-char) (following-char)) (forward-char) +(cond + ((and (= e 0) (= f 0)) + (* 0.0 (expt -1 s))) + ((and (= e 2047) (or (= f (1- (expt 2 52))) (= f 0))) + (* 1.0e+INF (expt -1 s))) + ((and (= e 2047) (not (or (= f 0) (= f (1- (expt 2 52)) + 0.0e+NaN) + (t + (* (expt -1 s) +(expt 2.0 (- e 1023)) +(1+ (/ f (expt 2.0 52 + (defun osc-server-set-handler (server path handler) "Set HANDLER for PATH on SERVER. IF HANDLER is nil, remove previously defined handler and fallback to @@ -205,6 +228,7 @@ the generic handler for SERVER." (lambda (type) (cl-case type (?b (osc-read-blob)) + (?d (osc-read-float64)) (?f (osc-read-float32)) (?i (osc-read-int32)) (?s (osc-read-string
Re: [BRLTTY] can't compile latest master.
Alexander Epaneshnikov writes: > hello. when I try to build latest master (a7942a637) I get this: DId you try running ./autogen? Sometimes, when things in the build system fail, you need to re-run ./autogen and/or ./configure to re-build the infrastructure for building the source... -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Accessible way to slow down music?
Howard Traxler writes: > Sébastien., I tried to get the Marion program from github but I > couldn't find a download link. How does one download from there? Now that I think of it, if you are running Debian, or one of its derivatives, you might also be able to install yatm by executing apt install yatm Otherwise, you need to build it from source: git clone https://github.com/mlang/yatm cd yatm cmake . make make install -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Unicode Braille
Dave Mielke writes: > [quoted lines by Raphaël POITEVIN on 2021/03/22 at 11:51 +0100] > >>It seems not working on my Active Star. > > Yes, because the ht key tables don't include the common chords > subtable. Perhaps this could be done. I don't perso0nally have access > to an ht device so I'm a little reluctant to mess with those tables > myself. It'd sure be a nice addition to 6.4, though. In the meantime, you should be able to switch between unicode and translated input via the preferences menu. Alternatively, you could create your own binding for BRLUCDOTS+on and BRLUCDOTS+off as well. For instance, you can copy /etc/brltty/Input/ht/as40.ktb to /etc/xdg/brltty/ (create the directory if necessary) and put your own binding in that file. Something like: bind SpaceLeft+B5+B7+B1 BRLUCDOTS+on bind SpaceLeft+B5+B7+B8 BRLUCDOTS+off (untested) -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Building without contracted braille support.
Dave Mielke writes: > Brltty can be built so that it doesn't contain support for contracted braille > - > via its configure's --disable-contracted-braille option. I'd like to remove > this capability, so I'm asking if anyone out there has a good reason not to do > this. The original reason, putting BRLTTY on a floppy disk, is definitely gone. I cant think of anything that would warrant keeping this preprocessor hackery, so I think it can savely go. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] mantis q40
Dave Mielke writes: > [quoted lines by Florian Beijers on 2021/02/10 at 17:14 +0100] > >>manually trusting the device first, > > Trusting only matters insofar as when connection to the host is being > requested > by the device. That isn't the case with brltty, i.e. it's always the case that > brltty on the host requests a connection to the device. Guessing here, but the poster has described that the Mantis has a bluetooth keyboard. My HT ActiveStar does a similar thing. Keyboard connected via USB to the device, but if you use it via Bluetooth, keycodes are not sent inline with the braille protocol, but sent via bluetooth HID. In that case, yu need to trust the remote device such that the keyboard can open a connection to the host, since that is how bluetooth keyboards usually work. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] mantis q40
Florian Beijers writes: > I see a whole lot of RFCOMM errors, either connection refused or resource > busy. > What would that indicate? My first question would be: Are you sure you have correctly paired the device? Does bluetoothctl report it as paired? -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] mantis q40
Florian Beijers writes: > Just tried pairing my APH Mantis q40 to a Kali machine running brltty 6.3, but > brltty seems to be unable to recognize it. > I''ve set the brailleDevice directive in brltty.conf to Bluetooth:address, > where > address is the address info returns from the bluectl command. > Enabled and started brltty with sudo systemctl, no errors but no braille > either. > I can't help but notice that there's no driver for it listed in brltty.conf > either. The "Mantis Q40" is supposed to work with the HumanWare (hw) driver. > Is this device supported over Bluetooth? It should be, since there is an entry for it in bluetooth_names.c. > If so, how can I further debug? Looking at the log might be helpful. Something like journalctl -u brltty.service should help in your case. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] tsi braille display serial protocol
deniz sincar writes: > or send me documentation how the serial bites are sent to display to > rise dots on cells? The source code is the documentation. https://raw.githubusercontent.com/brltty/brltty/master/Drivers/Braille/TSI/braille.c -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] bluetooth braille emulator
deniz sincar writes: > but i want it to act like a bluetooth focus 40 or something that > support iphone, and converts it to tsi braille protocol. There is no such thing. It would need to be written. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] tsi braille display driver
deniz sincar writes: > i want to try to make a tsi braille driver for nvda without using brltty. This question is probably best asked on a NVDA devs list. > how to do this? what are the communication packages for the display? What is a "communication package"? I would assume you already know that TSI displays only support serial communication. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Some symbols not displaying correctly after upgrade to Ubuntu 20.04
Dave Mielke writes: > [quoted lines by S. Massy on 2021/01/04 at 20:04 -0500] > >>Switching away from EN_US.UTF8 to fix date formats, > > You might find that en_IE is better than en_GB for that as it keeps the > overall > output format of the date command the same. The different LC_* variables can be set with different locales as well. I used to have LC_TIME=de_AT.UTF-8 and LC_MESSAGES=en_US.UTF-8. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] German users: no-break space and dot 7?
Sebastian Humenda writes: > Hi Mario > > Mario Lang schrieb am 05.12.2020, 21:27 +0100: >>Sebastian Humenda writes: >> >>> Mario Lang schrieb am 04.12.2020, 17:46 +0100: >>>>To all german users: I just noticed there is no mapping in de.ttb which >>>>maps to a sole dot 7. Any objections to mapping non-breaking spaces to >>>>dot 7? >>> >>> Why would you like to show non-breaking spaces by default? >> >>Because sole dot 7 is not used for anything. nbsp do carry a semantic >>meaning, i.e. they will inhibit editors to break between words using > […] > > Sure, but it's something related to typography in the wider sense. It should > be an option to enable for the screen reader or is the job of your editor to > show. The editor typically uses no-breaking space to show that, which is actually what we want from the perspective of screen reading. If the editor used some sort of background color, that wouldn't lend itself very much to screen reading. > I would not like to see it as a default. Why do you use a horizontal ellipsis in your email if you care about representablility in Braille? >>> They are not shown on the screen and I do not like the idea to do this >>> different in braille. A non-breaking space is IMHO a typographic >>> matter and I would say that it should be made visible when needed. >> >>Which character would you map to sole dot 7 then? > > Do we need to map it? Well, we only have 2^8 different things a braille cell can show. Is that so much that we can waste mappings? > I am not familiar with computer braille and whether there are > standards for this. Noted. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] German users: no-break space and dot 7?
Sebastian Humenda writes: > Mario Lang schrieb am 04.12.2020, 17:46 +0100: >>To all german users: I just noticed there is no mapping in de.ttb which >>maps to a sole dot 7. Any objections to mapping non-breaking spaces to >>dot 7? > > Why would you like to show non-breaking spaces by default? Because sole dot 7 is not used for anything. nbsp do carry a semantic meaning, i.e. they will inhibit editors to break between words using nbsp as a separator. IOW, nbsp can be used to separate things that really belong together, like the full name of a person or similar. When your editor does automatic line breaking for you, it will not break at an nbsp. > They are not shown on the screen and I do not like the idea to do this > different in braille. A non-breaking space is IMHO a typographic > matter and I would say that it should be made visible when needed. Which character would you map to sole dot 7 then? -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
[BRLTTY] German users: no-break space and dot 7?
Hi. To all german users: I just noticed there is no mapping in de.ttb which maps to a sole dot 7. Any objections to mapping non-breaking spaces to dot 7? -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] strange behavior udev and systemd
Aura Kelloniemi writes: > If I have many BRLTTYinstances running, will BrlAPI clients connect to > the right BRLTTY (i.e. will the latest BRLTTY be able to override the > BrlAPI server for the previously started instances)? There is no way to automatically determine what the "right" BRLTTY instance would be. It depends on what the user wants. They will likely need to configure the no-api directive in the respective brltty.conf to avoid conflicts. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] BRLTTY floods the log with the Freedom Scientific Focus Blue
Alex ARNAUD writes: > Hello all, > > I'm helping a blind user with a Freedom Scientific focus blue with the id > "0f4e:0114". I don't know the exact model sorry. It seems lsusb dosn't provide > us detailed informations about the device. lsusb -v refusing to provide details usually means even the kernel had trouble reading the device descriptors. > He uses: > > * Debian 10 "Buster" > * BRLTTY 6.1 > * The Linux kernel 5.8.10 > > BRLTTY floods the syslog and daemon files with the following logs: > > kernel: [ 1988.905326] usb 1-3: usbfs: USBDEVFS_CONTROL failed cmd brltty > rqt 128 rq 6 len 255 ret -71 These logs are from the kernel, not BRLTTY. > brltty[3434]: USB language code string read error > brltty[3434]: USB control transfer error 71: Erreur de protocole > brltty[3434]: USB language code string read error > brltty[3434]: USB configuration set error 22: Argument invalide > brltty[3434]: USB control transfer error 71: Erreur de protocole > brltty[3434]: USB configuration descriptor not readable: 0 > brltty[3434]: USB configuration descriptor not found: 1 > > It has produced 5 GB of logs and prevented X.Org to start. > > Based on our tests, the Braille device works. Which tests? On the same computer with Linux, or with some other OS? Also, is the user actually using the device? > Moving the log level to emergency doesn't seem to have produce any effects. Which log level? There are more log levels involved here. What the kernel reports, and what BRLTTY will log. > Defining the log file to /tmp/brltty.log continues to pollute the syslog and > daemon.log. > > What can we do to improve the situation? Currently we've unplugged the Focus > Blue and stop BRLTTY. Again, was the user actually using the device? If it was properly functioning, I wonder why BRLTTY was apparently retrying to initialize the device again and again. Could it be that more then just one BRLTTY were trying to fight over the same device? IOW, did you check that only one instance of BRLTTY was running? -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] 6.2 soon.
Samuel Thibault writes: > Lars Bjørndal, le ven. 20 nov. 2020 20:36:21 +0100, a ecrit: >> > For debian users, I have uploaded a snapshot of 6.2 in the experimental >> > distribution (versioned 6.2~pre+dfsg-1) so you can try it easily. >> >> Do you happen to also be responsible for the raspbian version of BRLTTY, > > No > >> do you have a corresponding package for that distro? > > I don't know if raspbian picks up packages from debian experimental too. Likely no. > I guess you could try to install the proper-armsomething package from debian. My raspian-fu is a bit rusty, but I'd try building the debian package from source. AIUI, most packages are taken unchanged from Debian. So if you build the Debian package from source on your pi, you should get the same binary package you would if raspian already had what you want to test. More specifically, you'd fetch the .dsc, .diff.gz and .tar.xz files from Debian with something like debget (or manually), run `dpkg-source -x` on the dsc, change into the directory, and build with something like `dpkg-buildpackage -uc -us`. You will likely need to install the build-dependencies. Most of which you will get with `apt-get build-dep brltty`. This is quite a mouthful, but as a result you should get a package which is easy to uninstall/upgrade without leaving stuff behind. And of course you are going to test if the packaging is compatible with raspian. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Generate visual Braille
Mario Lang writes: > root@x1:/etc/xdg/brltty# cat fr-names.ctb > include fr-abrege.ctb > always poitevin = Actually, now that I think again, you probably want to use the keyword "word" instead of "always". "word" will, as the name implies, only match complete words. "always" would also match if the string appears in the middle of a word. So the rule should likely read word poitevin = Have a look at Documents/README.ContractionTables (in the BRLTTY sourcedirectory) for a complete list of directives you can use in ctb files. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Generate visual Braille
raphael.poite...@gmail.com (Raphaël POITEVIN) writes: > Dave Mielke writes: > >> The contraction table itself would have to define that. I doubt that name >> detection is simple since, for example, the first word of a sentence is >> capitalized. > > echo "POITEVIN" | brltty-ctb -cfr-abrege > ⠨⠨⠏⠾⠞⠑⠧⠔ > > which is not attended. So you could define your own table, which would look like: root@x1:/etc/xdg/brltty# cat fr-names.ctb include fr-abrege.ctb always poitevin = root@x1:/etc/xdg/brltty# echo "POITEVIN" | brltty-ctb -cfr-names ⠨⠨⠏⠕⠊⠞⠑⠧⠊⠝ Some tables solve part of this problem by defining a list of common known names which should not (or only to a limited degree) be contracted. This is always just an approximation. Luckily, it is easy enough to define your own table as an extension of an existing one. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Being notified when battery level is low
Sébastien Hinderer writes: > Hello Mario, many thanks for your message! > > Mario Lang (2020/10/06 13:00 +0200): >> Sébastien Hinderer writes: >> >> > Raphaël POITEVIN (2020/10/06 10:21 +0200): >> >> Maybe a cron running a script which check the battery level with >> >> acpi. You can send a sound. >> > >> > Yeah that could be an option indeed. Thanks! >> >> if [ $(cat /sys/class/power_supply/BAT0/capacity) -lt 10 ] >> then play sound >> fi > > That was a great idea, thanks! I installed it as a cron job and it kind > of works, except when X is running becuase that starts PulseAudio, and > then the cron job is unable to play sound for a reason I don't know, it > seems it does not find PA so that's something that remians to be > investigated for me. The only advice I can give about PulseAudio is to uninstall the damn thing. PA is one of the reasons why I no longer use X on Linux. It is a horrible invasive piece of software. >> P.S.: It appears the same things are coming up over and over again for >> those of us who do not run a graphical desktop. > > Yes, I fully share the observation. > >> Screen curtain and >> battery status come to mind. > > I would maybe add automount... How is automount related? >> Maybe it is time to actually write a tool >> which somehow collects these small tasks into something that somehow >> just works. I would love to have something like >> apt install text-mode-junkie >> It would make it easy to turn down keyboard and display backlight, play >> a sound when battery is low and maybe offer current weather based on the >> current IP address. Basically what GNOME 2 used to offer as applets. > > I would also appreciate having all the features a graphical desktop > offers in text mode, but it feels it could be hard to maintain. It's > also my impression that we text-mode guys go a bit against the present > momentum and that it would be less painful to adapt ourselves to the > graphicla world than to try to resist to it. I am writing htis with some > sadness, I really don't like the graphical world. I am not resisting. I just refuse to use something which makes me less efficient. Also, I refuse to use something which can break from upgrade to upgrade. Remember GNOME3? Never ever will I trust the FLOSS community again to maintain an accessibile graphical environment. Last thing I read from the Orca maintainer felt a lot like she is about to burn out. Mostly because she feels like (and that is pretty much true) that the rest of the community is no longer interested in actually having a working accessible desktop. Things like Mutter and Wayland have pretty much demonstrated that we are not welcome. The next big shiny invention will lack proper accessiblity and we're out of the game again. Better not develop any dependency on the GUI, so nobody can rip it out of your heart again. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] BRLTTY with APH Mantis q40
brandybu...@protonmail.com writes: > Has anyone tried using braille with the mantis q40 by aph? My friend recently > aquired one and is looking for support. Me too, as i'm getting this exact > display. I always wonder how those work, i wonder if it runs android. But my > friend plugged it into his computer, the keyboard works fine with linux > because > it uses a separate driver apparently. But BRLTTY does nothing. Which version of BRLTTY did you try? The Q40 is supposed to work since BRLTTY 6.1 (April 6, 2020). -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Connecing BI 14 to Debian
Bertil Smark Nilsson writes: > I'm having problems connecting my Humanware BI 14 to my Debian 9 > machine via usb. Looking at the BRLTTY ChangeLog, it appears there was a problem with the BI 14 via USB which was fixed in BRLTTY 6.0. However, Debian 9 (codename stretch) has BRLTTY 5.4. If you can do so, upgrading your Debian installation to the latest stable release (codename buster, version 10) might fix the problem for you, as Debian 10 has BRLTTY 6.0. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Being notified when battery level is low
Sébastien Hinderer writes: > Raphaël POITEVIN (2020/10/06 10:21 +0200): >> Maybe a cron running a script which check the battery level with >> acpi. You can send a sound. > > Yeah that could be an option indeed. Thanks! if [ $(cat /sys/class/power_supply/BAT0/capacity) -lt 10 ] then play sound fi For those which use Emacs as their text desktop environment, there is M-x battery RET which will display battery status in the echo area and M-x display-battery-mode RET which will display battery status in the mode-line. I sometimes also use "acpi -bat" on the command line to check the temperature and how long I will be able to continue working on battery. P.S.: It appears the same things are coming up over and over again for those of us who do not run a graphical desktop. Screen curtain and battery status come to mind. Maybe it is time to actually write a tool which somehow collects these small tasks into something that somehow just works. I would love to have something like apt install text-mode-junkie It would make it easy to turn down keyboard and display backlight, play a sound when battery is low and maybe offer current weather based on the current IP address. Basically what GNOME 2 used to offer as applets. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Bug#971238: Expose RPCNFSDOPTS in /etc/default/nfs-kernel-server
Package: nfs-utils Version: 1:1.3.4-4 Severity: wishlist Tag: patch The ability to pass extra options (like --rdma) to rpc.nfsd is currently rather obscured. Looking at /lib/systemd/scripts/nfs-utils_env.sh, I see that RPCNFSDOPTS is being used. However, there is no stub for it in /etc/default/nfs-kernel-server. Since I was trying to enable RDMA, mentioning that option as an example seemed loke a good idea. --- nfs-utils-1.3.4/debian/nfs-kernel-server.default.orig 2020-07-26 14:02:00.0 +0200 +++ nfs-utils-1.3.4/debian/nfs-kernel-server.default 2020-09-27 21:20:25.375657576 +0200 @@ -1,6 +1,10 @@ # Number of servers to start up RPCNFSDCOUNT=8 +# Options for rpc.nfsd +# To enable RDMA on the server, specify '--rdma' here +RPCNFSDOPTS="" + # Runtime priority of server (see nice(1)) RPCNFSDPRIORITY=0 -- AR Mario Lang Phone: +43 316 873 6897 Graz University of Technology Mobile: +43 664 60 873 6897 IT-Services for research and teaching Email: ml...@tugraz.at Steyrergasse 30/1, 8010 Graz, Austria Please https://useplaintext.email/
Bug#971238: Expose RPCNFSDOPTS in /etc/default/nfs-kernel-server
Package: nfs-utils Version: 1:1.3.4-4 Severity: wishlist Tag: patch The ability to pass extra options (like --rdma) to rpc.nfsd is currently rather obscured. Looking at /lib/systemd/scripts/nfs-utils_env.sh, I see that RPCNFSDOPTS is being used. However, there is no stub for it in /etc/default/nfs-kernel-server. Since I was trying to enable RDMA, mentioning that option as an example seemed loke a good idea. --- nfs-utils-1.3.4/debian/nfs-kernel-server.default.orig 2020-07-26 14:02:00.0 +0200 +++ nfs-utils-1.3.4/debian/nfs-kernel-server.default 2020-09-27 21:20:25.375657576 +0200 @@ -1,6 +1,10 @@ # Number of servers to start up RPCNFSDCOUNT=8 +# Options for rpc.nfsd +# To enable RDMA on the server, specify '--rdma' here +RPCNFSDOPTS="" + # Runtime priority of server (see nice(1)) RPCNFSDPRIORITY=0 -- AR Mario Lang Phone: +43 316 873 6897 Graz University of Technology Mobile: +43 664 60 873 6897 IT-Services for research and teaching Email: ml...@tugraz.at Steyrergasse 30/1, 8010 Graz, Austria Please https://useplaintext.email/
Bug#970698: Please remove amd64 from NO_PMIX_ARCH
Package: openmpi Version: 4.0.5-4 Severity: important Right now, debian/rules has NO_PMIX_ARCH:= armel mipsel amd64 This looks like an oversight. I get an error about undefined symbol when launching an MPI job via SLURM. Removing amd64 from NO_PMIX_ARCH fixes this. -- AR Mario Lang Phone: +43 316 873 6897 Graz University of Technology Mobile: +43 664 60 873 6897 IT-Services for research and teaching Email: ml...@tugraz.at Steyrergasse 30/1, 8010 Graz, Austria Please https://useplaintext.email/
[elpa] externals/chess 2d797ff 1/2: * chess-game.el (chess-game-ply): Fix docstring.
branch: externals/chess commit 2d797ff3a3e9d8e0019feec7fa99a34b5d15ad42 Author: Mario Lang Commit: Mario Lang * chess-game.el (chess-game-ply): Fix docstring. --- chess-game.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chess-game.el b/chess-game.el index d86f159..06b99fb 100644 --- a/chess-game.el +++ b/chess-game.el @@ -222,7 +222,7 @@ if INDEX is nil)." (defun chess-game-ply (game index) "Return a ply of GAME. -If INDEX is non-nil, the last played ply is returned." +If INDEX is nil, the last played ply is returned." (cl-assert game) (if index (nth index (chess-game-plies game))
[elpa] externals/chess updated (31a581b -> 7193c24)
mlang pushed a change to branch externals/chess. from 31a581b * chess-pgn.el (chess-pgn-parse): Fix unescaped character literal new 2d797ff * chess-game.el (chess-game-ply): Fix docstring. new 7193c24 * chess-network.el (chess-network-handler): Use `executable-find'. Summary of changes: chess-game.el| 2 +- chess-network.el | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
[elpa] externals/chess 7193c24 2/2: * chess-network.el (chess-network-handler): Use `executable-find'.
branch: externals/chess commit 7193c24769d463ae8920a2f8143f8cc3d0122eb1 Author: Mario Lang Commit: Mario Lang * chess-network.el (chess-network-handler): Use `executable-find'. --- chess-network.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chess-network.el b/chess-network.el index c9a6b3d..16f7aa7 100644 --- a/chess-network.el +++ b/chess-network.el @@ -144,7 +144,7 @@ (string-to-number (read-string "Port: "))) (start-process "*chess-network*" - (current-buffer) "/usr/bin/nc" + (current-buffer) (executable-find "nc") "-l" "-p" (read-string "Port: "))) (open-network-stream "*chess-network*" (current-buffer) (read-string "Host: ")
Re: [BRLTTY] brlapi programming examples
Mika Hanhijärvi writes: > I just would like to create my own braille tetris :-) I have written a braille tetris recently. However, it does not use BrlAPI, it uses Unicode Braille characters to display the state of the game directly on the console. You can find it here: http://hackage.haskell.org/package/betris If you install the Haskell Stack tool, you can easily build it with: git clone https://github.com/mlang/betris cd betris stack build If that is too complicated, you can also get the prebuilt executable from here: wget https://blind.guru/betris chmod +x betris ./betris When playing, remember that this is a horizontal version of tetris. So the functions of the cursor keys has been rotate as well. Cursor up/down will move the tile, and cursor left will drop it. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Can BRLTTY indicaste indentation?
"John J. Boyer" writes: > Consider the following deeply indented Python statement. > wordType = adverb > There are five tabs. I would like BRLTTY to replace them with simicolons > ;wordType = adverb > This feature would have to be optional and easy to turn on and > off. People sometimes use spaces to indicate indentation or even both > tabs and spaces. I would like spaces replaced with commas. The feature > should work only at the beginnings of lines. I've soon code with soo > many tabs that the Braille display is blank. > That makes coding really frustrating. This is how life goes. I firmly believe what you want is best handled by your editor. If you are already using Emacs, it should be pretty simple to get what you want with emacs lisp. If you are working with a codebase that strictly uses tabs, you might also improve things by setting the tab width. In vi, for instance, you can always do :set tabstop=2 to make deeply nested code which uses tabs easier to read. Regarding the indentation width, I personally feel like 2 is the minimum for easily feeling how far something is actually indented. I never liked just one space, it is confusing to me and too easy to miss things while scrolling along a block of code. Dealing with code formatting in contributions to open source projects can be tedious sometimes. However, there is no real way around this. It is totally understandable for most projects to demand a unified style when starting to accept patches. The codebase would be horribly inconsistent when it comes to formatting and indentation after awhile. Sometimes, you can make tools work for you. For instance, some languages (C++ and Rust come to mind) have quite capable code formatting tooling these days. If a project uses that, you can sometimes get away by temoprarily modifying the code formatting rules, do your work, and switch them back to what the project requires before finally submitting your patch. In most other cases, you are pretty much on your own. However, this is a pain we share with the sighted community. For instance, a sighted coworker of mine refused to meaningfully indent his code (in languages that do not require indentation). This was very confusing to me whenever I had to look at his code. To me, proper indentation is part of the beauty of code, even in languages that do not require it. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Can BRLTTY indicaste indentation?
"John J. Boyer" writes: > Hello, > > I am considering trying to help with the development of Orca. However, > I need a way to indicate indentation in Python. > I thought of trying to get emacs to do this, but it is really the > business of the screenreader. So I am wondering if BRLTY has a way of > indicating indentation. I don't understand. I am a braille only user, and have worked with several programming languages that depend on indentation (Haskell, Python). I have never needed special support from my screen reader. What is it exactly, that you are looking for? -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] [OT] How to integrate BSI into a Linux cell phone?
Rich writes: > I'm a sighted, semi-retired, volunteer developer who is very interested in the > possibility of re-purposing Android cell phones as blind-accessible computing > and communication devices. There are a number of projects working on re-using > the billions of aging cell phones that are out there. Some, such as > LineageOS, > start with an open source version of Android. Others, such as postmarketOS > and > Mobian, start with a more vanilla flavor of Linux (e.g., Alpine, Debian). > > Although the first approach makes tons of Android software available, most of > this is GUI-based, so accessibility will generally be a challenge. Basing the > system on Linux allows a wealth of CLI-based software to be used and helps to > anchor the resulting system more closely in the open source community. I can follow your analysis. I dont agree with some of its conclusions, but lets continue. > Challenges > > One of the biggest challenges, I suspect, will be providing an accessible form > of text input. Most screen-based keyboards for cell phones aren't suitable, > a physical keyboard would add cost and bulk, and voice recognition (without > the > support of cloud computing) still seems to be beyond the phone's capabilities. Voice Recognition also conflicts with your idea of a CLI-based system. A physical keyboard doesn't sound like a real problem. However, if you want to aim for a completely mobile solution, BSI as you call it seems like the best option around. > So, I've been speculating about how to support Braille Screen Input (BSI) on a > Linux-based cell phone. BSI is available on Android, Fire OS, and iOS (please > let me know if I'm missing any others!), but I haven't found any indication > that > anyone is working on supporting it for any form of Linux. I guess the reason for that is that plain Linux systems running on a worn-out mobile device aren't really populare amongst blind users. Cost-wise, Rasperry Pis are very much more populare when it comes to building a low-cost computing solution. Adding a USB keyboard doesnt really drive up the cost, and is very easy to do. If you dont care for high performance applications, as a blind user, you're basically done now. There is no real need for a monitor, for instance. > I think I have a handle on how to architect the front end of the code, using a > set of Actors (lightweight processes) running on a foundation of Elixir, > Erlang, > and OTP. Are you saying you want to implement the motion tracking for the multitouch screen with the stack you mention above? Or do you plan to write your applications with that stack? > However, I'm totally out of my depth when it comes to interfacing the > code to other apps, the window system, and the rest of the OS. You seem to be contradicting yourself. At the beginning, you argue that a plain Linux system is better because it doesn't have a GUI. Now, you are looking for ways to interface wtih a windowing system. I am confused. > Should I be looking into D-Bus, GTK, Qt, or what? That really depends on what sort of applications you are trying to support on your system. If I wanted to write a BSI for CLI on Linux, I'd be looking into the Linux kernel input device API. You can simulate a keyboard in software with that. How you talk to your multitouch screen devices is totally out of my knowledge. > Also, are there any ways the code could leverage BRLTTY, Emacspeak, > Orca, etc? How would typical blind users want a BSI subsystem to act > in this context? I'm really confused here, so I'm asking for advice, > comments, and so forth. Frankly, you dont quite understand the ecosystem you are trying to adapt. Orca is only relevant if you decide to go for a GUI based system. Emacspeak is pretty specific to Emacs users, although I guess it could be used as the main audio desktop if you want to go that way. BRLTTY should be easy to plug in, if you are either using virtual terminals or something that requires Orca. > > -r > > P.S. There is at least one physical keyboard which isn't totally out of the > question for use with a cell phone. I am pretty sure there are more then just one. -- AR Mario Lang Phone: +43 316 873 6897 Graz University of Technology Mobile: +43 664 60 873 6897 IT-Services for research and teaching Email: ml...@tugraz.at Steyrergasse 30/1, 8010 Graz, Austria Please https://useplaintext.email/ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
[BRLTTY] ALVA Satellite 584 Pro
Hi. I am looking for someone who has used a ALVA Satellite 584 Pro at some point. I am trying to debug one which is slightly unstable when used via USB. I was hoping to just use the serial port, but for some reason I can not turn the device on without USB connected. Does anyone know, was there perhaps a magic trick to switch the device to external power. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Raspberry Pi bluetooth pairing question
"Keith Wessel" writes: > I feel like I'm overlooking something obvious here. > > I recently replaced my aging Gentoo desktop system with a Pi 4, and I'd like > to pair my braille disply with it via bluetooth. But I'm getting hung up on > the connecting. > > [bluetooth]# connect E0:7D:EA:E7:91:FF As far as I understand, you shouldn't need to use connect. Did you read Documents/README.Bluetooth? -- AR Mario Lang Phone: +43 316 873 6897 Graz University of Technology Mobile: +43 664 60 873 6897 IT-Services for research and teaching Email: ml...@tugraz.at Steyrergasse 30/1, 8010 Graz, Austria Please https://useplaintext.email/ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] error after i run make / keycodes description
Stéphane Doyon writes: > On Thu, 28 Nov 2019, Dave Mielke wrote: > >> Your brlapi_constants.h is nearly empty. It should be much larger - mine has >> a >> little over 400 lines in it. This looks very similar to a problem that was >> reported, here, about a week ago. The problem was that some of the awk >> scripts >> that building brltty uses were compatible with gawk but not with mawk. What >> does the AWK = line in config.mk say? >> >> This problem has now been fixed. Please, therefore, get the latest brltty >> development source and give it another try. > > I'm not sure if this regressed, but I'm encountering this problem > again, building at head as of right now on Raspbian Buster. > And > > sudo apt install gawk > > fixed it. This is a know issue. Debian installs mawk by default, while some of the awk scripts in BRLTTY do require gawk. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Git directory not includes the baum branch.
Anders Holmberg writes: > After i type make -s should i then do make install or just try to run > the ./run-brltty? run-brltty was written so that you can run brltty from its build directory without having to install it. In other words, always use run-brltty if you are just testing a particular build/change. -- CYa ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Logging levels
Sebastian Humenda writes:
> I am looking for the different logging options that I could pass to BRLTTY to
> log different event categories, e.g., speech or keyboard input.
brltty -H
...
-l lvl|cat,...--log-level= Logging level (0-7 or one of
{emergency alert critical
error warning notice information
debug}) and/or log categories to
enable (any combination of {all
ingio inpkts outpkts brlkeys
kbdkeys csrtrk csrrtg update speech
async server serial usb bluetooth
brldrv spkdrv scrdrv}, each
optionally prefixed by - to disable)
--
CYa,
⡍⠁⠗⠊⠕
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.app
For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] BRLTTY and SSH from Windows
Lars Bjørndal writes: > I had to reinstall my Windows pc at work. Previously I used BRLTTY and > Cygwin SSH to access remote servers. That worked pretty well. Anyway I'd > like to ask if it's better, nowadays, to use the linux console in > Windows, than using Cygwin. I had pretty good results with WSL (1 and 2). Works pretty nicely, and is pretty easy to install. > Is it possible to install BRLTTY with apt-get and use it from the > Linux console? I never tried this. I use a normal Windows screen reader (JAWS and/or NVDA in my case). BTW, if all you need is ssh, Windows 10 comes with ssh preinstalled. So depending on your requirements, it might be enough to just use that from cmd. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] latest git fails on osx
rmgls writes: > i am trying to build a binary Which binary, exactly? And how do you try to build it? > and clang complains about -lcrt0.o not found. What is the exact error message? > msdos is not disabled by default? This bit doesn't make a lot of sense in the given context. In general, please try to be a bit more specific when asking questions. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Key bindings for the HandyTech products
[Top-posting to keep the answer short.] Hi. I personally use the binding of CURSOR_UP and CURSOR_DOWN quite a lot. And, as you already said, if I don't want to reach all the way to the right, I use the SPACE keys to pan horizontally. Sébastien Hinderer writes: > Dear all, > > This message is addressed to Mario and all the users of the Active Star > 40 and perhaps also other HandyTech products. > > I would like to discuss the binding of the left triple action key. Its > lower part is currently bound to cursor down, while its upper part is > currently bound to cursor up. > > I never used these bindings and recently changed them. I bound the lower > part to full window right and the upper part to full window left. That > may sound counterintuitive and may seem more intuitive to do the binding > the other way around, but my idea was to be as close as possible to > what one is doing when reading printed braille. When one is doing that, > at some point the right hand continues to read on its own while the left > one returns to the beginning of the line and goes to the following one, > so that the right hand knows where to go when reading is finished. > > With this bindings, I find the load of my two hands more balanced. It's > also convenient when the display is not completely filled to not have to > go to the triple action key on the right to go to the next braille > window. I realise I could do it with the space keys, too, but I don't > find this very convenient. > > So my question is: what do other users of this input table think about > this suggestion? Do you find it odd and think I should just keep it for > myself, or do you like it and find it worth including? > > For those who would like to try, I am attaching the updated version of > rockers.kti I am using. > > To use it, just install it under /etc/xdg/brltty/rockers.kti and restart > brltty, it will load the alternative version of the table rather than > the default one. > > Best wishes, > > Sébastien. > > > ___ > This message was sent via the BRLTTY mailing list. > To post a message, send an e-mail to: BRLTTY@brltty.app > For general information, go to: http://brltty.app/mailman/listinfo/brltty > -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Tr: Fwd: Google Launches Braille Keyboard for Android Devices
Sébastien Hinderer writes: > The message below may be of interest. Wow, it took them what, 4 or 5 years? to steal this feature from iOS :-) -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] BRLTTY does not recognize my braille line, "braillino"
discapacidad5 writes: > El lun., 23 dic. 2019 a las 13:49, Dave Mielke () escribió: > > The braille line has a built-in braille keyboard, the part of the braille > line and navigation work well, but the 8-point typing keyboard that it brings > built in does not work You likely need to switch from navigation to input mode. Try pressing RightSpace+Dot7+Dot8. To go back to navigation mode, press LeftSpace+Dot7+Dot8. -- CYa, ⡍⠁⠗⠊⠕ ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
[elpa] master updated (4db95ab -> 2604824)
mlang pushed a change to branch master. from 4db95ab Concatenate messages instead of using a temp-buffer and buffer-string new dcb301b Support for binary blobs new 2604824 Release version 0.2 Summary of changes: packages/osc/osc.el | 31 +-- 1 file changed, 25 insertions(+), 6 deletions(-)
[elpa] master 2604824 2/2: Release version 0.2
branch: master commit 2604824e5dfbe1ba23210f9d5c966fd8918832c4 Author: Mario Lang Commit: Mario Lang Release version 0.2 --- packages/osc/osc.el | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/packages/osc/osc.el b/packages/osc/osc.el index 5450751..a63d382 100644 --- a/packages/osc/osc.el +++ b/packages/osc/osc.el @@ -3,7 +3,7 @@ ;; Copyright (C) 2014-2019 Free Software Foundation, Inc. ;; Author: Mario Lang -;; Version: 0.1 +;; Version: 0.2 ;; Keywords: comm, processes, multimedia ;; This program is free software; you can redistribute it and/or modify @@ -39,11 +39,11 @@ ;; Usage: ;; -;; Client: (setq my-client (osc-make-client "localhost" 7770)) +;; Client: (setq my-client (osc-make-client "127.0.0.1" 7770)) ;; (osc-send-message my-client "/osc/path" 1.5 1.0 5 "done") ;; (delete-process my-client) ;; -;; Server: (setq my-server (osc-make-server "localhost" 7770 +;; Server: (setq my-server (osc-make-server "127.0.0.1" 7770 ;; (lambda (path args) ;;(message "OSC %s: %S" path args
[elpa] master dcb301b 1/2: Support for binary blobs
branch: master commit dcb301bb9894e2862183317622e6207bc0b8e8ed Author: Mario Lang Commit: Mario Lang Support for binary blobs * packages/osc/osc.el: (osc-blob, osc-read-blob): New functions. * (osc-send-message, osc-filter): Adjust. --- packages/osc/osc.el | 25 ++--- 1 file changed, 22 insertions(+), 3 deletions(-) diff --git a/packages/osc/osc.el b/packages/osc/osc.el index e88f135..5450751 100644 --- a/packages/osc/osc.el +++ b/packages/osc/osc.el @@ -35,7 +35,7 @@ ;; BUGS/TODO: ;; -;; * Timetags and binary blobs are not supported yet. +;; * Timetags are not supported yet. ;; Usage: ;; @@ -55,6 +55,12 @@ (setq string (encode-coding-string string 'binary)) (concat string (make-string (1+ (- 3 (% (length string) 4))) 0))) +(defun osc-blob (vector) + (let ((length (length vector))) +(concat (osc-int32 length) + vector + (make-string (% (- 4 (% length 4)) 4) 0 + (defun osc-float32 (value) (let (s (e 0) f) (cond @@ -112,6 +118,7 @@ ((floatp arg) "f") ((integerp arg) "i") ((stringp arg) "s") +((vectorp arg) "b") (t (error "Invalid argument: %S" arg args))) (mapcar @@ -119,7 +126,8 @@ (cond ((floatp arg) (osc-float32 arg)) ((integerp arg) (osc-int32 arg)) - ((stringp arg) (osc-string arg + ((stringp arg) (osc-string arg)) + ((vectorp arg) (osc-blob arg args (defun osc-read-string () @@ -129,6 +137,16 @@ (forward-char (- 4 (% (length string) 4))) string)) +(defun osc-read-blob () + (let* ((length (osc-read-int32)) +(pos (point)) +(vector (progn + (forward-char length) + (string-to-vector (buffer-substring pos (point) +(padding (% (- 4 (% length 4)) 4))) +(forward-char padding) +vector)) + (defun osc-read-int32 () (let ((value 0)) (dotimes (i 4) @@ -179,13 +197,14 @@ the generic handler for SERVER." (goto-char (point-min)) (let ((path (osc-read-string))) (if (not (string= path "#bundle")) - (when (looking-at ",") + (when (= (char-after) ?,) (save-excursion (apply (osc-server-get-handler proc path) path (mapcar (lambda (type) (cl-case type + (?b (osc-read-blob)) (?f (osc-read-float32)) (?i (osc-read-int32)) (?s (osc-read-string
[elpa] master 4db95ab: Concatenate messages instead of using a temp-buffer and buffer-string
branch: master commit 4db95ab266983bf89adcd17d17b91aee1a1b43b4 Author: Mario Lang Commit: Mario Lang Concatenate messages instead of using a temp-buffer and buffer-string * packages/osc/osc.el: (osc-float32, osc-int32, osc-string): New functions. * (osc-insert-float32, osc-insert-int32, osc-insert-string): Remove. * (osc-send-message): Adjust. --- packages/osc/osc.el | 59 + 1 file changed, 32 insertions(+), 27 deletions(-) diff --git a/packages/osc/osc.el b/packages/osc/osc.el index 316b532..e88f135 100644 --- a/packages/osc/osc.el +++ b/packages/osc/osc.el @@ -51,10 +51,11 @@ (require 'cl-lib) -(defun osc-insert-string (string) - (insert string 0 (make-string (- 3 (% (length string) 4)) 0))) +(defun osc-string (string) + (setq string (encode-coding-string string 'binary)) + (concat string (make-string (1+ (- 3 (% (length string) 4))) 0))) -(defun osc-insert-float32 (value) +(defun osc-float32 (value) (let (s (e 0) f) (cond ((= value 0.0) @@ -73,18 +74,17 @@ (if (= e 0) (while (< (* f (expt 2.0 e)) 1.0) (setq e (1+ e (setq f (round (* (1- (* f (expt 2.0 e))) (expt 2 23))) e (+ (* -1 e) 127 -(insert (+ (lsh s 7) (lsh (logand e #XFE) -1)) - (+ (lsh (logand e #X01) 7) (lsh (logand f #X7F) -16)) - (lsh (logand f #XFF00) -8) - (logand f #XFF +(unibyte-string (+ (lsh s 7) (lsh (logand e #XFE) -1)) + (+ (lsh (logand e #X01) 7) (lsh (logand f #X7F) -16)) + (lsh (logand f #XFF00) -8) + (logand f #XFF -(defun osc-insert-int32 (value) +(defun osc-int32 (value) (let (bytes) (dotimes (i 4) (push (% value 256) bytes) (setq value (/ value 256))) -(dolist (byte bytes) - (insert byte +(apply 'unibyte-string bytes))) ;;;###autoload (defun osc-make-client (host port) @@ -99,23 +99,28 @@ ;;;###autoload (defun osc-send-message (client path args) "Send an OSC message from CLIENT to the specified PATH with ARGS." - (with-temp-buffer -(set-buffer-multibyte nil) -(osc-insert-string path) -(osc-insert-string - (apply 'concat "," (mapcar (lambda (arg) - (cond - ((floatp arg) "f") - ((integerp arg) "i") - ((stringp arg) "s") - (t (error "Invalid argument: %S" arg - args))) -(dolist (arg args) - (cond - ((floatp arg) (osc-insert-float32 arg)) - ((integerp arg) (osc-insert-int32 arg)) - ((stringp arg) (osc-insert-string arg -(process-send-string client (buffer-string + (process-send-string + client + (apply +'concat +(osc-string path) +(osc-string + (apply + 'concat "," + (mapcar (lambda (arg) + (cond +((floatp arg) "f") +((integerp arg) "i") +((stringp arg) "s") +(t (error "Invalid argument: %S" arg + args))) +(mapcar + (lambda (arg) + (cond + ((floatp arg) (osc-float32 arg)) + ((integerp arg) (osc-int32 arg)) + ((stringp arg) (osc-string arg + args (defun osc-read-string () (let ((pos (point)) string)
[elpa] master d56dd03: Improve single precision floating point serialisation
branch: master commit d56dd0378c5f8a582066c636599be1f297691142 Author: Mario Lang Commit: Mario Lang Improve single precision floating point serialisation * packages/osc/osc.el: Update copyright years and author email. * (osc-insert-float32): Use `copysign' and `isnan'. --- packages/osc/osc.el | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/packages/osc/osc.el b/packages/osc/osc.el index 9f92b17..316b532 100644 --- a/packages/osc/osc.el +++ b/packages/osc/osc.el @@ -1,8 +1,8 @@ ;;; osc.el --- Open Sound Control protocol library -;; Copyright (C) 2014 Free Software Foundation, Inc. +;; Copyright (C) 2014-2019 Free Software Foundation, Inc. -;; Author: Mario Lang +;; Author: Mario Lang ;; Version: 0.1 ;; Keywords: comm, processes, multimedia @@ -57,15 +57,13 @@ (defun osc-insert-float32 (value) (let (s (e 0) f) (cond - ((string= (format "%f" value) (format "%f" -0.0)) - (setq s 1 f 0)) - ((string= (format "%f" value) (format "%f" 0.0)) - (setq s 0 f 0)) + ((= value 0.0) + (setq s (if (< (copysign 1.0 value) 0) 1 0) f 0)) ((= value 1.0e+INF) (setq s 0 e 255 f (1- (expt 2 23 ((= value -1.0e+INF) (setq s 1 e 255 f (1- (expt 2 23 - ((string= (format "%f" value) (format "%f" 0.0e+NaN)) + ((isnan value) (setq s 0 e 255 f 1)) (t (setq s (if (>= value 0.0)
Re: [BRLTTY] Bluetooth
Lars Bjørndal writes: > I recently installed Fedora 30 to a Raspberry pi 3B+. Now, I have the > problem that my Handy Tech Active Braille sometimes will not connect > when BRLTTY starts. Instead I get the message Pair y/n on the > display. If I answer > yes, I get the pairing question repeatedly, also if I reboot the pi. Did you change the firmware on the active star in any way? To my experience, later versions of the active star firmware do behave in unexpected and basically unusable ways when it comes to bluetooth. Have you tried to repair it manually? ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Bug#872468: Still exists
Hi. I am seeing the mentioned warnings ( WARNING: Unknown key type EIGHT_LEVEL_LEVEL_FIVE_LOCK ) whenever setupcon is executed on a stable buster installation. The contents of my /etc/default/keyboard is as follows: -- XKBMODEL="sun_type7_euro_usb" XKBLAYOUT="de,de" XKBVARIANT=",neo" XKBOPTIONS="grp:rwin_toggle,ctrl:nocaps" BACKSPACE="guess" -- These warnings appear since I enabled the "neo" variant.
Bug#872468: Still exists
Hi. I am seeing the mentioned warnings ( WARNING: Unknown key type EIGHT_LEVEL_LEVEL_FIVE_LOCK ) whenever setupcon is executed on a stable buster installation. The contents of my /etc/default/keyboard is as follows: -- XKBMODEL="sun_type7_euro_usb" XKBLAYOUT="de,de" XKBVARIANT=",neo" XKBOPTIONS="grp:rwin_toggle,ctrl:nocaps" BACKSPACE="guess" -- These warnings appear since I enabled the "neo" variant.
