K5 [Kindle Touch] xterm & matchbox-keyboard

[baf]

Originally Posted by aditya3098

Weird bug detected! If my command starts with "ipkg" then it freezes before I finish the command.

I can't replicate this bug.

In the meantime I updated my XTerm package. I added keyboard shortcuts to open popup menus and change font size.

• <ALT> 1 => opens popup main menu
• <ALT> 2 => opens popup vt menu
• <ALT> 3 => opens popup font menu
• <ALT> - => decreases font size
• <ALT> = => increases font size

You can also easily customize terminal, shortcuts or fonts by editing Xresources file in xterm/layouts folder within the package.

[NiLuJe]

@aditya3098: Wild guess: Broken bash auto-completion stuff?

(I don't use bash, but when I'm messing around with zsh and the auto-complete stalls, it 'hangs' @ 100% CPU until I ^C).

[knc1]

Originally Posted by baf

I can't replicate this bug.

In the meantime I updated my XTerm package. I added keyboard shortcuts to open popup menus and change font size.

• <ALT> 1 => opens popup main menu
• <ALT> 2 => opens popup vt menu
• <ALT> 3 => opens popup font menu
• <ALT> - => decreases font size
• <ALT> = => increases font size

You can also easily customize terminal, shortcuts or fonts by editing Xresources file in xterm/layouts folder within the package.

A question -
I don't see a row for function keys, f1..f10(12) but I do see a "F" meta key.
So are the function keys generated with the F 1 .. F 10 key pair sequence?
If so, does <ALT> F 1 sequence work? Or will it work before your done?

The reason I ask, the virtual terminals are accessed via <ALT>F1 ... <ALT>F10 (or F12) - however many of them you have turned on in /etc/inittab.

[hawhill]

In fact, the terminals you can access on a typical Unixoid system nowadays are virtual, but not pseudo terminals. The OS presents them as /dev/ttyN, not /dev/ptyN / /dev/pts/N. xterm however will create a pseudo terminal. You can't switch among these with ALT-F<n>, since they do not necessarily have "siblings". However, you can use a terminal multiplexer like screen or tmux to archieve a similar effect. I'm using tmux within myts here on my K3.

[knc1]

Originally Posted by hawhill

In fact, the terminals you can access on a typical Unixoid system nowadays are virtual, but not pseudo terminals. The OS presents them as /dev/ttyN, not /dev/ptyN / /dev/pts/N. xterm however will create a pseudo terminal. You can't switch among these with ALT-F<n>, since they do not necessarily have "siblings". However, you can use a terminal multiplexer like screen or tmux to archieve a similar effect. I'm using tmux within myts here on my K3.

Hmm...

Capturing the alt-F* keys is a function of the keyboard handling, not of xterm (in this thread, of matchbox-keyboard).
The function is to start (and switch to) another instance of xterm on another /dev/tty* (of those with a handler assigned in /etc/inittab).

A terminal multiplexer, does just that, multiplexes a single terminal instance, not create a new one. Those applications are from the days when the user only had a single set of wires to a single, physical, terminal interface.
Not related to my question concerning keyboard handling in matchbox-keyboard.

[wl.]

wow, midnight commander looks really nice now

[baf]

Originally Posted by knc1

A question -
I don't see a row for function keys, f1..f10(12) but I do see a "F" meta key.
So are the function keys generated with the F 1 .. F 10 key pair sequence?

As far as matchbox-keyboard is concerned it handles <Fx> keys. You change layout pressing "ã/F" key. See screenshot.
But it will not change terminal for reasons mentioned by Hawhill.
Also I noticed that some keystokes are intercepted by kindle. This is the case with <Fx> keys. You may overcome this by selecting securekbd option (which ensures that input is directed only to xterm) from XTerm popdown menu.
<Fx> keys are not pair sequences. They have their own character codes. For example <F1> sends 0xffbe. For more keycodes see for example here.

Edit: By the way, the only KT key sends 0xff50, which is mapped to <home> key

[hawhill]

Originally Posted by knc1

Capturing the alt-F* keys is a function of the keyboard handling, not of xterm (in this thread, of matchbox-keyboard).

Well, to some extent. I can only speak for Linux, but there, it's as follows: The Kernel switches from using pure /dev/console over to /dev/ttyN when sysvinit tells it to. On /dev/ttyN, the kernel will typically handle ALT-F* and switch VGA console output between the /dev/ttyN devices. When X is running, it captures one of the /dev/ttyN devices, nowadays often overriding the ALT-F* combinations. Note that the Kernel will only switch between the *virtual* terminals /dev/ttyN here. Also, the Kernel is the instance that runs the terminal emulation for /dev/ttyN.

Graphical terminals however don't use the virtual terminals /dev/ttyN. They use pseudo terminals. For those, there is always a _pair_ of devices. Nowadays this will be the /dev/ptmx (single master for all slaves) and /dev/pts/N (slave terminal, this side is for terminal clients).
This mechanism is what xterm uses. You can't switch from pseudo terminals to virtual terminals: just try on a desktop in xterm to switch. All you potentially get is a full screen VGA terminal, but xterm has nothing to do with that, that's kernel based switching between virtual terminals, i.e. the whole X session and another virtual tty.

The function is to start (and switch to) another instance of xterm on another /dev/tty* (of those with a handler assigned in /etc/inittab).

Possible, but a multiplexer will do that for you, too.

A terminal multiplexer, does just that, multiplexes a single terminal instance, not create a new one. Those applications are from the days when the user only had a single set of wires to a single, physical, terminal interface.
Not related to my question concerning keyboard handling in matchbox-keyboard.

Well, it creates a new terminal device (or uses a new terminal device for old PTY style rather than PTS) for the sub-sessions of the "multiplexer". And in fact, tmux is relatively new, not from an old era. There's still good use for those applications today. An additional benefit is that you can keep your terminal session running in the "background" (detach/reattach).

[knc1]

Yes, indeed, I follow all of that.
A nice, clear, explaination for the benefit of those readers less experienced here.

What I was asking about would have been __non-standard__ behavior that (after thinking / sleeping on the question) would require that (since this is running under X) <CTRL><ALT>F* to start another instance on a __different__ X11 display (which would be on a different /dev/tty* - since one is already captured).

Not impossible, but probably not worth the programming effort.

Which gets me to where I was headed anyway.

So while this "heavy weight" on-Kindle terminal display is useful in itself;
The other project here, http://www.mobileread.com/forums/sho...d.php?t=178983 of JoppyFur is also still useful.

If it does not involve (I don't think it is an X11 app) the graphical display system, then it would be much easier to add virtual terminal support to that project.

Since the majority of the readers on this forum are probably not *nix users, it may be hard for them to imagine "why" support for the multiple virtual terminals would be useful.

Answering those questions might lead to a fairly long thread, and it would be probably better to open a "VT Support" thread once JF gets his project closer to being finished.

[geekmaster]

Originally Posted by knc1

...
So while this "heavy weight" on-Kindle terminal display is useful in itself;
The other project here, http://www.mobileread.com/forums/sho...d.php?t=178983 of JoppyFur is also still useful.

If it does not involve (I don't think it is an X11 app) the graphical display system, then it would be much easier to add virtual terminal support to that project.

JoppyFur's terminal uses only native mode access to the framebuffer and input event devices, based on methods that I published in "signature capture" and "eink algorithmic art" threads, also used in my published C programs. JoppyFur's program can run with the framework stopped, so it can be used in a RUNME.sh script for debricking purposes. With minor changes (different input device), it can be used when booting from diags as well. In my sigcap script, I scan input devices searching for the "zforce" touchscreen device, so it works on both main and diags.

[knc1]

Originally Posted by geekmaster

JoppyFur's terminal uses only native mode access to the framebuffer and input event devices, based on methods that I published in "signature capture" and "eink algorithmic art" threads, also used in my published C programs. JoppyFur's script can run with the framework stopped, so it can be used in a RUNME.sh script for debricking purposes. With minor changes (different input device), it can be used when booting from diags as well. In my sigcap script, I scan input devices searching for the "zforce" touchscreen device, so it works on both main and diags.

So there is another list of good reasons for JF to continue his work.
Keep on coding JF, this project has not replaced what you are doing.

[JoppyFurr]

Originally Posted by knc1

So there is another list of good reasons for JF to continue his work.
Keep on coding JF, this project has not replaced what you are doing.

Hi,

Yeah, I'm still working on my terminal when I have time. After the end of this week I'll be on by break between semesters one and two, so will be able to get a good chunk of development in. However, for the rest of this week, I have two more exams, so won't have much coding time 'til after they are over.

I do plan on eventually having a tabbed interface for multiple terminal sessions running in parallel.

[roman220]

I recently install xterm app, but seems to be pressing upper key "C" does nothing, lower one works. Am I unlucky or is it a real bug? Thanks.

[geekmaster]

Originally Posted by roman220

I recently install xterm app, but seems to be pressing upper key "C" does nothing, lower one works. Am I unlucky or is it a real bug? Thanks.

You have source code. You can answer your own question. If you find a bug, you can even fix it.

[roman220]

Originally Posted by geekmaster

You have source code. You can answer your own question. If you find a bug, you can even fix it.

I don't feel "the force with me" yet... Im unfamilar with Kindle developing, but trying to get into ) geekmaster, did the "C" works on your one? )