[BRLTTY] HandyTech's TOUCH_AT feature and BRLTTY's learn mode

[Mario Lang]

Sébastien Hinderer <sebastien.hinderer at ens-lyon.org> writes:

> Mario Lang (2026/04/02 11:23 +0200):
>> Sébastien Hinderer <sebastien.hinderer at ens-lyon.org> writes:
>>
>> > For those who don't know: the devices from Handy Tech can report the
>> > finger's position on the braille display.
>> >
>> > I am not sure how known / used this feature is, but thinking about it I
>> > can imagine very cool uses, e.g. fast double touch on a link would
>> > simply open it in a browser, or do whatever you want with that link.
>>
>> You'll have to experiment.  The protocol used to be a lot
>> more versatile.  With initial ATC implementations from HT,
>> *every* cell sent a pressure value, so you could even see several
>> fingers / do a kind of multi-touch.  We implemented
>> highlighting on-screen, so a sighted co-worker could actually
>> see (by background colour) what text you were currently touching/reading.
>> I used that at work for a few years.
>> In later firmware revisions, they unfortunately removed that capability
>> and replaced it with a single "finger position", whatever that means.
>> I was particularily unhappy as a customer/developer because
>> HT changed my firmware while doing device service, so the new
>> reduced feature-set was kind-of forced down my throat without my
>> consent.
>
> I don't know at what firmware version the change happened.

I was talking about HT Evolution 88, and its firmware.
That device was released 2006.  I believe the forced downgrade
of functionality was somewhere around 2010.  So we are likely
talking about different devices.  I believe what you have
is a Active Star?

>> Current ATC is still useful, but the biggest use case seems to boil down to
>> TOUCH_NAV.
>
> I must say, I don't know what ATC means. Active Touch Cells?

Active Touch Control, which is, AFAIK, a HandyTech patent.

>> BRLTTY implements that, which you should be able to turn
>> on with Chord+Dot1+Dot4 (Capital-A for ATC).
>
> Is Chord a key in itself, or do you just mean to press dots 1 and 4
> together, actually?

No, a "chord" combination in braille context is usually
some dot combination pressed together with space.
I guess it is more common in german...

So I mean "press dot1, dot4 and left space".

>> The idea is, if
>> you have finished reading a line, BRLTTY will automatically advance
>> the display to the next reading position.  Especially useful
>> for reading books and other longer texts.
>
> Okay yes, I get the idea. I believe I prefer to have the control on the
> scrolling and it would stress me if it would be done before I agree on
> it to happen.

Well, tell me one blind person who is not a control freak...
But thats not what this is about.  I hinted already that the
feature is likely only really useful when reading longer texts.

In any case, this is what we get for free, basically.
Since ATC is just using the fact that the piezzo-effect goes both ways.
You can make piezzo bend by applying electricity, and
you can emit electricity by bending it.  Apparently, it took the
refreshable braille display industry to realize and implement this,
what, almost 30 years?  Kind of reflects on the innovation-factor in
blind assistive technologies :-)

>> > For the time being: I notice that, when BRLTTY's learn mode is run
>> > interactively, the TOUCHAT events are not shown. I find this convenient
>> > because of course, to read you have to teach so whatever key ou press,
>> > if its description is immediately replaced by a TOUCHAT event, then you
>> > won't see it and the whole purpose of learn mode is defeated. But this
>> > does not happen in BRLTTY's interactive learn mode, fortunately.
>> > However, it does happen when running apitest in learn mode. And to some
>> > extent it makes sense. But should we have an option for apitest to
>> > ignore some keycodes / blocks?
>>
>> Since brlapi already provides keycode/command filters, I am surprised
>> apitest doesn't already do so?
>
> I assume either apitest has been implemented before this feature appeared, or
> it was tested only with devices that do not implemnet it, so that the
> problem was actually never encountered.

I wasn't refering to ATC, just the fact that BrlAPI supports
command filtering.  So I would have guessed apitest supports
that in some way, if it is only to test filtering?

>> > Also, one question to the owner of Handy Tech devices: I thought it was
>> > possible to completely disable the fiongers detection feature but I just
>> > checked the option menu (firmare 2.0 of an Active Star 40) and couldn't
>> > find any relevant option, apart from something that I think makes the
>> > finger detection more or less sensitive, but even with the lowest level
>> > I was still getting the TOUCHAT events in apitest.
>>
>> I believe we currently unconditionally enable ATC during driver
>> initialisation.  What we *could* possibly do is ignore the touch events
>> in the core if TOUCH_NAV is off, but that feels a bit hacky, since
>> theoretically, other future features could also rely on that event.
>
> If there indeed is a possibility to choose at initialization time
> whether the feature is enabled or disabled, wouldn't it be nicer to have
> a driver parameter to control this? I wouldn't mind the parameter being
> enabled by default. But I think if one is not interested at all by the
> feature then it's better to disable it completely rather than letting
> the event flow from the device to the PC and then ignore them
> afterwards.

I know you know C.  Patches welcome.
However, At least in my book, it would make more sense to fix apitest to
include a filter, if you reqally use it that much.

-- 
CYa,
  ⡍⠁⠗⠊⠕