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

[Araki K. <ara...@us...>]

 Hi,

From: Didier Spaier <di...@sl...>
Subject: Re: [Mlterm-dev-en] Input buffered in mlterm-fb?
Date: Thu, 18 May 2017 00:35:31 +0200
Message-ID: <aef...@sl...>

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

 mlterm-fb reads stdin instead of /dev/input/event* if opening /dev/input/event*
fails or KBD_INPUT_NUM=-1.
 The mode of reading stdin disables mlterm-fb to distinguish modifier keys etc,
so mlterm-fb prefers /dev/input/event* to stdin.

 BTW, I'm sorry but I doesn't hit upon the reason why nothing comes from /dev/input/event0.

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

 I'm confused.
 I have no idea why KBD_INPUT_NUM=-1 results in "Integrated keyboard" while
KBD_INPUT_NUM=14 thru 30 results in "Both keyboards".

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

 Thanks, please test an attached patch (which has been already committed to hg head)
 It will fix these problem.

 Regards,
---
Araki Ken
ara...@us...