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

[Sébastien Hinderer]

Mario Lang (2026/04/13 18:56 +0200):
> > 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?

Yes, absolutely. And I was under the impression that you had that one,
too, but perhaps you have both.

> >> 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".

I see. Thanks.

> >> 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.

Frankly, even for such one I seem to not be interested.

> >> > 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?

Nope, at least not the C one.

I think nobody ever took the time to dsign command-line options to
express all the filtering possibilities.

> >> > 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.

I wanted to discuss the idea first.

> 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.

I'd prefer the driver parameter approach so if you agree with the
principle yes, I may very well submit a patch for a driver parameter.
Wouldit be okay to call it atc with values yes and no, yes being the
default? Oh well if the parameter name is fine I will look at the code
and see what can be specified at device initialization and make sure
there are enough values for the parameter to reflect the different
choices.

Seb.