[Mlterm-dev-en] Fwd: Re: Input buffered in mlterm-fb?

[Didier S. <di...@sl...>]

Hi,

I resend this message without the attachments now stored in
http://slint.fr/testing/mlterm/
as it has been held until now for this reason:
  Message body is too big: 170941 bytes with a limit of 40 KB
Fortunately it will go through this time.

Regards,
Didier


-------- Message transféré --------
Sujet : Re: [Mlterm-dev-en] Input buffered in mlterm-fb?
Date : Thu, 18 May 2017 00:35:31 +0200
De : Didier Spaier <di...@sl...>
Pour : mlt...@li...

Hi,

in this message I will answer your last post but also bring other issues.

I hope this is acceptable.

Le 13/05/2017 à 19:59, Araki Ken a écrit :
> From: Didier Spaier <di...@sl...>
>> Le 08/05/2017 à 18:30, Araki Ken a écrit :
>> I already checked, but here goes:
>>
>> didier[~]$ for f in * ; do echo $f; cat $f; done
>> 0 
>> AT Translated Set 2 keyboard
>> 1 
>> Speakup
>> 10 
>> HDA Intel PCH Headphone
>> 11 
>> Video Bus
>> 12 
>> Logitech USB Optical Mouse
>> 13 
>> BRLTTY 5.4 Linux Screen Driver Keyboard
>> 3 
>> Lid Switch
>> 4 
>> Sleep Button
>> 5 
>> Power Button
>> 6 
>> ThinkPad Extra Buttons
>> 7 
>> HDA Intel PCH Mic
>> 8 
>> HDA Intel PCH Dock Mic
>> 9 
>> HDA Intel PCH Dock Headphone
> 
>  How about starting mlterm-fb with 13 
> 
>  If it solves the problem, I'll fix mlterm-fb to prefer BRLTTY keyboard to
> normal AT keyboard.
It didn't work

Anyway I don't think that brltty comes into play in the issue. I made
more tests without it:

1) tests with just the intagrated keyboard of my laptop and an optical
USB mouse pluged in.

didier[~]$ for f in /sys/class/input/input*/name; do printf $f|sed 's,[^[:digit:]]*,,;s,/.*,,'; printf " ";cat $f; done|sort -g
0 AT Translated Set 2 keyboard
1 Speakup
3 Lid Switch
4 Sleep Button
5 Power Button
6 ThinkPad Extra Buttons
8 HDA Intel PCH Mic
9 HDA Intel PCH Dock Mic
10 HDA Intel PCH Dock Headphone
11 HDA Intel PCH Headphone
12 Video Bus
16 Logitech USB Optical Mouse
didier[~]$ 

Value of KBD_INPUT_NUM with which the keyboard works
-1
1
11
12
14
15
16
17
18
19
20

As expected setting KBD_INPUT_NUM a to a non-existent <num> throws an
error:
  ERROR(No such file or directory): Couldn't open /dev/input/event<num>
but in many cases doesn't prevent the keyboard to work. I am still
puzzled. I had a look to uitoolkit/fb/ui_display_linux.c, alas I am not a 
developer and don't understand what I read.

2) thest after having plugged off, then on the optical mouse and plugged
in an external USB keyboard.

didier[~]$ for f in /sys/class/input/input*/name; do printf $f|sed 's,[^[:digit:]]*,,;s,/.*,,'; printf " ";cat $f; done|sort -g
0 AT Translated Set 2 keyboard
1 Speakup
3 Lid Switch
4 Sleep Button
5 Power Button
6 ThinkPad Extra Buttons
8 HDA Intel PCH Mic
9 HDA Intel PCH Dock Mic
10 HDA Intel PCH Dock Headphone
11 HDA Intel PCH Headphone
12 Video Bus
22 Logitech USB Optical Mouse
23 BTC USB Multimedia Keyboard
24 BTC USB Multimedia Keyboard
didier[~]$ 

Value of KBD_INPUT_NUM with which at least one keyboard works:
-1 Integrated keyboard
1  Integrated keyboard
14 thru 30 Both keyboards
I assume that all values > 14 are OK
Very big values (100, 1000, 9999999) Both keyboards

These results look similar to those from the first tests.

>> Which leads to an off topic question. nosh is supposed to be able
>> to provide two outputs if I understand well: one to draw a framebuffer
>> and another to provide discrete characters that can be read by brltty.
>> Can mlterm do something similar[1]? Cf:
>> https://jdebp.eu/Softwares/nosh/brltty.html
>> https://jdebp.eu/Softwares/nosh/user-vt-screenshots.html
> 
>  I'm not familiar to brltty and nosh at all.
> 
>  As far as I looked over them, it seems possible to enable mlterm to
> output characters to brltty, though I haven't understand yet the natural
> way of processing characters to be output to brltty.
> 
>  http://mlterm.sf.net/mlterm-3.8.1-brltty.patch is a simple patch, and
> I tested brltty as follows.
> 
> $ tar xzvf mlterm-3.8.1.tar.gz
> $ cd mlterm-3.8.1
> $ patch -p1 < mlterm-3.8.1-brltty.patch
> $ ./configure ...
> $ make; sudo make install
> $ export BRLTTY_SPEECH_INPUT=~/tmp_fifo
> $ brltty -s es -E
> $ mlterm

I can't comment on that brltty by lack of knowledge but as per my above
testing report the issue existq even when the brltty daemon is not
started.

Also, I have a blind friend who helps me for testing but he only uses the
output of his Braille display: he reads with the fingers, do not use
speech synthesis, and do not use a Braille keyboard but a regular one.

I will have to investigate further anyway if we want to help blind people
speaking one of the CJK languages, so let's concentrate on that later.

---

Issue #2:

If I start mlterm-fb say from /dev/tty2 then switch to an X display with
Ctrl+Alt+F7, the Xserver having been started on /dev/tty1 for instance,
this result in mlterm using 100% of one of my 4 CPU cores.

As son as I switch back to /dev/pts/2 (whre mlter-fb is running) this
percentage decreases to a (expected) very low value as expected. But I
for instance I switch to /dev/tty3, the CPU% increases again and if
htop is running in /dev/pts/2 artefacts from the display in /dev/pts/2
appear in /dev/tty3. I have no idea why.

---

Issue #3

I observed that using the 'dialog' program in mlterm, if used without the
"--colors=false" options triggers errors shown in the attached file
debuglog, altough the output seems OK. This occurs under X as well as in
a framebuffer.

I attach also the displayed dialog (under X) and  two output of the ANSI
sequences displaying it, one in raw and the other in ttyrec formats, both
in a framebuffer. The displayed dialog is the same under X or in a
framebuffer.

---

Please feel free to request any information and testing that could help
you investigate these issues and thanks for your time.

Best regards,

Didier