[BRLTTY] Linux console hacking (was: Re: Footsteps towards better accessibility in Linux)

[Nicolas Pitre]

On Mon, 30 Mar 2026, Samuel Thibault wrote:

> Nicolas Pitre, le lun. 30 mars 2026 10:18:50 -0400, a ecrit:
> > On Mon, 30 Mar 2026, Sébastien Hinderer wrote:
> > 
> > > Thank you Nicolas, I am very impressed.
> > > 
> > > My only feedback would be about cursor routing, which is a topic Samuel
> > > and I have been discussing off-line a few weeks ago.
> > > 
> > > My understanding is that the way it's currently done is because we
> > > cannot currently do better, but I think if we could we should.
> > > 
> > > More concretely, if kmscon supports input from a mouse, then I'd suggest
> > > that cursor routing events are somehow translated to mouse clicks. In
> > > terms of your doocuemnt I assume this would mean adding one more type of
> > > events that BRLTTY could inject?
> > 
> > I think mouse clicks and cursor routing should remain separate. They 
> > sometimes have the same effect (like within a text editor) but often 
> > they're different.
> > 
> > The idea is for BRLTTY to tell the terminal: "I want a mouse click event 
> > here" and use routing keys for indicating the location through a 
> > different key binding than cursor routing. It is then up to you to use 
> > the method that provides best results in a given context.
> 
> The problem is that it would need applications to be extended to support
> routing. Leveraging their existing support for mouse clicks would be
> very effective to get things working.

Agreed. The protocol I'm proposing already includes a mouse click 
injection message for exactly this purpose. I've also just added a mouse 
mode flag to the terminal state flags, so BRLTTY could know whether the 
application is listening for mouse events and could potentially choose 
the best strategy accordingly.


Nicolas