MiSTer Web Control demo

[Locutus73]

There is one problem - it will output to HDMI only.

From a purely scripting standpoint there should be no problem: you could open the scripts with the old menu while on VGA and with the framebuffer terminal while on HDMI. Scripts can detect that and, if a proper terminal is found, they can (it's just an example) implement a fully interactive GUI through ncurses/dialog, while when they detect the old menu they can just go full automatic with basic textual output.

Regards.

Locutus73

[Sorgelig]

There is a big problem came with frame buffer implementation and use TTY.
TTY always listen and executes the keyboard input. This is why my linux originally was headless.
Now i have to deal with TTY (virtual terminal) and find the way to block the keyboard when it's not visible to user.
So far i cannot find explicit way to block the keyboard on TTY. There are some other awkward ways like EVIOCGRAB which doesn't work reliably and through loadkeys by re-defining the keys to NULL which is slow to setup.
So i have to find the way to turn off/on keyboard for TTY before will add it to MiSTer.
So, i need help from community.

[Locutus73]

There is a big problem came with frame buffer implementation and use TTY.
TTY always listen and executes the keyboard input. This is why my linux originally was headless.
Now i have to deal with TTY (virtual terminal) and find the way to block the keyboard when it's not visible to user.
So far i cannot find explicit way to block the keyboard on TTY. There are some other awkward ways like EVIOCGRAB which doesn't work reliably and through loadkeys by re-defining the keys to NULL which is slow to setup.
So i have to find the way to turn off/on keyboard for TTY before will add it to MiSTer.
So, i need help from community.

Interesting, I was thinking that something similar (but reverse) could happen trying to inject keyboard events from main MiSTer using the joypad... those events could return to main MiSTer, but you have total control in that case. I'll try to see if I find something, I think I can simulate the same scenario on a Linux virtual machine.

Regards.

Locutus73

[Locutus73]

There is a big problem came with frame buffer implementation and use TTY.
TTY always listen and executes the keyboard input. This is why my linux originally was headless.
Now i have to deal with TTY (virtual terminal) and find the way to block the keyboard when it's not visible to user.
So far i cannot find explicit way to block the keyboard on TTY. There are some other awkward ways like EVIOCGRAB which doesn't work reliably and through loadkeys by re-defining the keys to NULL which is slow to setup.
So i have to find the way to turn off/on keyboard for TTY before will add it to MiSTer.
So, i need help from community.

I tried this code https://stackoverflow.com/a/7672324 in a vmware virtual machine and it seems to work.
From SSH I got exclusive access to /dev/input/event0 (AT Translated Set 2 keyboard) and when I try to type something into the VMWare Player main window I get nothing there, instead I get the keycode in the SSH window.

[EDIT]
My bad, you already found the EVIOCGRAB solution, excuse me...

[EDIT2]
What did you find unreliable in the EVIOCGRAB solution? I tested it only with the VM and it seems to work, but I didn't test MiSTer...

[EDIT3]
Very stupid question... do we need agetty always running and attacched to TTY?
Can it be launched and killed just when we need a console directly by main MiSTer?

[EDIT4]
Maybe the [EDIT3] could be achieved through the use of different runlevels, so we could have a runlevel without agetty and one with agetty connected to TTY and main MiSTer could swap runlevel when we need a console.



P.S.: sorry for the many edits.

Regards.

Locutus73

[Sorgelig]

Of course it's possible to run getty when you switch to linux screen, and kill when you switch to the core's screen.
But i find this usage very limited. I find it useful to not interrupt the terminal session. It may be useful to have it in parallel. Sometimes it's good to debug something.

With some additional tweaks and workarounds i can use EVIOCGRAB. So with release it will be possible to see what side effects it can bring.

[kitrinx]

Of course it's possible to run getty when you switch to linux screen, and kill when you switch to the core's screen.
But i find this usage very limited. I find it useful to not interrupt the terminal session. It may be useful to have it in parallel. Sometimes it's good to debug something.

With some additional tweaks and workarounds i can use EVIOCGRAB. So with release it will be possible to see what side effects it can bring.

I did this once to disable terminal keys, not sure it is the best way but it works somewhat:

Code: Select all

		struct termios term;

		tcgetattr(fileno(stdin), &term);
		term.c_iflag |= IGNBRK;
		term.c_iflag &= ~(IXON | IXOFF);
		term.c_lflag &= ~(ECHO | ECHOK | ECHOE | ECHONL | ISIG);
		tcsetattr(fileno(stdin), TCSANOW, &term);

[Sorgelig]

Of course it's possible to run getty when you switch to linux screen, and kill when you switch to the core's screen.
But i find this usage very limited. I find it useful to not interrupt the terminal session. It may be useful to have it in parallel. Sometimes it's good to debug something.

With some additional tweaks and workarounds i can use EVIOCGRAB. So with release it will be possible to see what side effects it can bring.

I did this once to disable terminal keys, not sure it is the best way but it works somewhat:

Code: Select all

		struct termios term;

		tcgetattr(fileno(stdin), &term);
		term.c_iflag |= IGNBRK;
		term.c_iflag &= ~(IXON | IXOFF);
		term.c_lflag &= ~(ECHO | ECHOK | ECHOE | ECHONL | ISIG);
		tcsetattr(fileno(stdin), TCSANOW, &term);

Interesting info. Will explore it if EVIOCGRAB will give problems.

[Sorgelig]

By the way, about the remote control.
Kernel supports USBIP. I never tried it, but it seems it's exactly for remote control.