[BRLTTY] [OT] How to integrate BSI into a Linux cell phone?

Anders Holmberg anders at pipkrokodil.se
Wed Aug 19 09:38:59 EDT 2020


Hi!
Its an intresting thought though.
So i am intrested in this.
/A

> 18 aug. 2020 kl. 07:48 skrev Aura Kelloniemi <kaura.dev at sange.fi>:
> 
> Rich <rdm at cfcl.com> writes:
>>> On Aug 17, 2020, at 09:03, Mario Lang <mlang at blind.guru> wrote:
>>> A physical keyboard doesn't sound like a real problem.
> 
>> I'm mostly basing this on comments by a blind friend who uses an old, small
>> iPhone for much of her Internet access.  She is unhappy that all of the new
>> iPhones are larger than she wants or needs; carrying around a keyboard (even
>> a small, folding one) would be a nuisance.
> 
> I kinda understand her. When I'm running to a bus stop while trying to check
> out the time tables with one hand at the same time (the other hand holding
> the white cane), I really prefer if I don't also need to hold a braille
> display and a physical keyboard at the same time.
> 
> I think there are two very different use scenarios here:
> 
> 1. A mobile computer with braille & speech support
> 
> Here we don't need BSI (or the touch screen at all) for input, because we have
> a big braille display anyways, we can as well add a physical keyboard. Many
> braille displays have a braille input system available too.
> 
> I suppose that with PostmarketOS this setup is already very easy to achieve. A
> rebuilt kernel with VT support is probably the only thing needed.
> 
> (Rich, for your information, braille with BRLTTY is not really supported in
> graphical terminal emulators. Emulators that support at-spi2 are
> accessible to some extent, but this support is not up for day-to-day use. I
> have never managed to get good (low-latency) support for braille in Orca. Orca
> in general, is a grief.)
> 
> 2. A mobile phone accessible anywhere without additional devices
> 
> For this scenario BSI really is a good way to go for input, I think. But
> still it has a problem of not being accessible with one hand. Maybe a huge
> full-screen virtual keyboard grid might be another option. BSI and VKBD don't
> need to cancel each other out.
> 
> For output, speech is the only option here (see my running scenario above).
> 
> But this usage pattern is not supported by any existing applications in normal
> Linux world. All applications that the user wants to access need to have
> a special user interface.
> 
> Answering a phone call with a command sequence like this, would be very
> inconvenient:
> 
> $ call-manager list
>  N   Caller          Phone number   Status   Time
> Incoming calls:
>  #1  Mom             +358491234567  Ringing  2020-08-18T09:03:15 +0300
> Outgoing calls:
>  #0  The Hot Date    +358459876543  Active   2020-08-18T08:59:42 +0300
> $ call-manager set-hold #0
> Call #0 (to The Hot Date) set on hold
> $ call-manager accept #1
> call-manager: #1: No such call
> 
> (As you can see, my Mom has already disconnected before I could typ alll the
> commands needed to answer her call.)
> 
> Applications, which cannot be operated using CLI commands at least include a
> web browser, phone call manager, text editor, messaging application (this
> being the easiest to convert to a CLI setup) ...
> 
> Basically, if you are not willing to implement a complex desktop accessibility
> system from scratch, X windowing is of no use here. Orca is written in Python,
> and it has latency issues even on a modest desktop PC, let alone a worn-out
> ARM device.
> 
>> Join the club :-).  The reason I mention a windowing system (really, desktop)
>> is that most Linux systems I've seen seem to bundle session management and
>> other features into something like MATE.  Ideally, however, I'd like the system
>> to work without that overhead.
> 
> As a blind user, I mostly don't have access to a desktop session. I need to
> adapt my computer usage patterns to that. BRLTTY does not really work well in
> a graphical environment. That's why almost everybody here (I think) uses a
> plain Linux VT. If we had the resources to make BRLTTY work well in a
> graphical terminal emulator, we would have done that long ago. For example, we
> would have enjoyed full unicode support and extended character attributes for
> ages.
> 
> The sad thing is that desktop accessibility is a broken addition to the Linux
> desktop standards, and support for accessibility in Linux world is a low
> priority for most developers.
> 
> This needs to be taken into account when choosing a viable target system for a
> mobile phone.
> 
> Either a lot of supporting infrastructure has to be developed for use in X, or
> power management/session handling needs to be ported to the text-only
> environment of a virtual console.
> 
> I would guess that the first option (of using X) would be preferred from an
> average user's viewpoint – for example nowadays people expect to be able to
> browse the web with their phones (even many blind people do).
> 
> From a developer's perspective, the option B of porting the necessary bits to
> the console world sounds more applealing to me – it is just so much simpler.
> 
> -- 
> Aura
> _______________________________________________
> This message was sent via the BRLTTY mailing list.
> To post a message, send an e-mail to: BRLTTY at brltty.app
> For general information, go to: http://brltty.app/mailman/listinfo/brltty



More information about the BRLTTY mailing list