I'm developing serial terminal sw and trying to resolve asynchronous screen size.
Below is in detail
There are modem_[a,b] and modem_a's uart1, _b's uart0 are connected(Main console port of both is uart0).
serial_app on modem_a attempts to access to modem_b via serial line.
serial_app uses termios library
And it's possible to serial-access to modem_b then it provides terminal service like putty.
But I change console window size then it starts asynchronous display.
However, I execute resize command then it becomes fixed.
So I checked SIGWINCH and it was triggered on modem_a but not on modem_b. And I've looked for how to pass SIGWINCH through serial terminal or cause SIGWINCH over modem_b controlling terminal settings like ioctl_tty(), escape sequence(\e[8;$Height;$Width, ...) , and so on...
Eventually I failed..
I'd like to maintain synchronous display whenever I change window size.
So you guys, Do you have a solution? or anything else?
I found out why I was unable to automatically synchronize window size and display on serial terminal. It's just there is not a mechanism on serial terminal.
So, we should manually synchronize window by resize command on that.
Reference:
source : http://lists.busybox.net/pipermail/busybox/2009-May/069226.html
source : https://wiki.archlinux.org/index.php/Working_with_the_serial_console
Related
I want to detect a key combination like alt+g in an application that runs as a background process (other keypresses/combinations should be executed normally) ,
if the combination is pressed i want to block all keypresses and send them via serial to another linux pc instead of executing them. I cannot find a solution for detecting the key combination and recording the keys within a background process.
I'd prefer to use a bash script, but c is ok aswell.
I just cant find a starting point. Any directions or help are appreciated.
Using Xlib I managed to fetch the keyboard Input http://www.x.org/releases/X11R7.7/doc/libX11/libX11/libX11.html
Doesn't the application screen do what you want? Allows you to detach & reattach to sessions on another PC over network (which could be connected over a serial line)?
10 Screen command examples and
How to use Linux Screen
Is it possible to disable input to an already existing x11 window? In the following Stack Overflow question How to prevent an X Window from receiving user input? it is suggested that it might be possible to do this with xprop but I don't really understand what the xprop input is supposed to be.
Using xprop I also notice there is a window property called WM_TAKE_FOCUS that perhaps can be deleted somehow? Is there not a x11 api call to disable all input equivalent to the Windows api call EnableWindow which disables all input?
Edit:
Tried deleting WM_TAKE_FOCUS, doesn't seem to change anything sadly..
You can open a window that doesn't hijack the keyboard. Let's simplify this using a command with options.
open my.pdf -no_input
A process that maintains control of the input device after opening a window, regardless of focus.
When I am running firefox as my active application and do a [ctrl]+[shift]+T, firefox opens a new tab. Hoever when I do a [ctrl]+[alt]+T, linux opens a new terminal window. Just made me ponder over the possible internals of this operation.
I had assumed that the control over stdin lies with the active application and if it reads something that makes sense to it, it goes ahead and does it. Now I feel that before the input is even put into stdin, the kernel scans it for the shortcuts that are relevant to it, and only the ones leftover are passed onto stdin, and from there to the user space applications.
Is this view accurate?
You are correct about what is causing it, just not the details. It's not the kernel that is swallowing it in this case, it's the Window Manager.
Your keyboard shortcut for Ctrl+Alt+T is getting eaten by your window manager. If you go to your Window Manager keyboard shortcuts, find the one bound to Ctrl+Alt+T and un-define it, it will work in FF properly.
The WM is a "layer" if you will that receives all events and passes on the ones that it determines are relevant to the underlying application.
Currently I am working on J2ME App and I am facing command issue in j2me.
When I am adding any command on form its coming under options, not coming directly on screen.
Command selCommand = new Command("Select");
This select command is not coming directly on screen, options is coming on screen then click on option command then Select command is coming.
I want Select command on screen instead of option.
High Level GUI coding in JavaME doesn't let you decide how a Command should be displayed.
The same code may display a Command directly on the screen on some devices, but under Options on other devices. So don't have any control of that.
Your best chance is to look into priorities. By setting a high priority on your Command, you may be lucky that it displays directly on the screen instead of under Options. It is not something you should count on though, since it's not required by the specification, but I suspect at least many devices would do that.
J2ME doesn't let you allow to add commands on Screen it will come in menu but we can set priority to command so that they can be visible in left or right side.
even if you want to add command on Screen you have to use buttons.
Container containerbtn;
Button btnsel = new Button("Select");
containerbtn.addComponent(btnsel );
this.addComponent(containerbtn);
I have an application that sends the focus to other windows but those windows then don't automatically display themselves in the foreground, i.e. on top of all the other windows. Where can I configure the preferences of my window manager so that this is the default behaviour?
In particular I'm using the Ctrl-0 and Ctrl-Shft-0 shortcuts in the MATLAB IDE to move between the command window and the editor window and although the focus seems to be transferred the new window doesn't automatically redraw itself in the foreground.
Not sure of a key binding off hand that does it, but if you alt-click on a window (which allows you to drag a window) it should come to the front.
As codeDr suggests, MATLAB is also kind of bad about repainting its windows. If you draw to a figure while code is executing, the figure does not update unless you execute drawnow or have some similar pause in the execution to allow the GUI to repaint. Since we're talking about MATLAB, the figure command will also cause the indicated figure to come to the front (in fact, it's harder to get it to not come to the front). So you could do figure(gcf) to bring the current figure to the front, or save the figure number with h = figure; and then later do figure(h). Incidentally, if you want to switch current figures without switching focus, set(0, 'CurrentFigure', h) should set h to the current figure.
Your window manager (probably Metacity?) implements focus-stealing prevention so that rogue apps don't pop up windows that would disturb your typing. Matlab needs to raise its window, and give it the input focus with the correct timestamp. If this is being done from a KeyPress event handler, the timestamp for setting the input focus would be the timestamp from the KeyPress event (i.e. the timestamp of the user-generated event that caused a window to be raised/focused).
To politely give the input focus to a window, google for _NET_ACTIVE_WINDOW.
Usually when the window doesn't repaint, it means that the application's main application loop isn't running to refresh the window. Could it be that Matlab is doing some computation or disk activity when you are switching between windows?