Page MenuHomePhabricator

Terminology: mouse move events - "button" byte wrong?
Open, NormalPublic


When an application requests classic mouse capture mode Esc[?1003h then on moving the mouse terminology sends Esc[M and next byte as 0x1f - those move-reporting terminals that I've checked (namely gnome-terminal and urxvt) send 0x43 instead.

If the application also requests "sgr 1006" mode, then the first decimal for a move event is -1 while gnome-terminal sends decimal 35. I haven't found any "official" documentation about "sgr 1006" mode, so maybe terminology is correct here and g.-t. wrong...

There were also cases where it randomly reported a drag as moves or did not send moves at all until I clicked, but I don't see a reproducible pattern for those, yet.

avl42 created this task.Nov 10 2016, 7:59 AM
avl42 updated the task description. (Show Details)Nov 10 2016, 8:13 AM
jpeg assigned this task to billiob.Feb 21 2017, 1:40 AM
jpeg added a project: Terminology.
jpeg renamed this task from mouse move events - "button" byte wrong? to Terminology: mouse move events - "button" byte wrong?.

How do you test it?

avl42 added a comment.EditedMar 4 2017, 10:31 AM

My testcase was a java application using Lanterna text-gui library. I'm also involved in Lanterna development, and submitted a patch to Lanterna in the meantime to support terminology.

testing can of course also be done by setting terminal mouse mode by echo'ing the sequences, then stty'ing to raw and starting some hexdump utility.

PS: I'm not an expert on these matters. I only noticed that terminology is different from other terminals, still can't tell what it is the right thing.