I am working on to enable Wandboard Quad(IMX6Q) Uart 2 features for to get data from GPIO3_26 and GPIO3_27 I enabled Uart2 from dts and recompiled imx6q-wandboard.dtb file ,it seems its working but
when I send the "hello" to ttymxc1 I m seeing the senseless charachters , even if I adjust same baudrate ttymxc1 and my machıne ttyUSB0 (I m using usb to rs232 converter ). I think I need to close some features but I dont know what is it or I need to make some configuration pinmuxing and ALT modes .
Is there any way to change the ALT modes of the features or when we choose the UART or another features it is enabling the dependent ALT Mode ?
Can you give me a suggestion or what Am I doing wrong ?
Must_ba
Related
I would like to build an AHK script that will press Fn + D and Fn + G for me when executed.
Unfortunately, after checking the "key history" from an an AHK script where I enabled "KeybdHook", it appears that my keyboard's Fn key doesn't trigger any key action when pressed.
Should I give up all hope?
Unnecessary context :
On my 65% keyboard, Fn + [Key] shortcuts are pivotal for replacement of various missing keys, as well as for changing various keyboard settings.
In particular, RGB settings are changed using Fn + D and Fn + G — and, annoyingly, they reset to a default, ugly rainbow every time I restart my computer, instead of a more subdued RGB setting which I prefer. The script I am trying to build would change these settings automatically on startup (until my brain grows large enough to comprehend QMK, my keyboard's RGB software)
Thanks in advance. I fully expect bad news.
QMK has a good diagram of how keyboards work:
+------+ +-----+ +----------+ +----------+ +----+
| User |-------->| Key |------>| Firmware |----->| USB wire |---->| OS |
+------+ +-----+ +----------+ +----------+ +----+
When you press a key on your keyboard the QMK Firmware inside the keyboard interprets the key presses and creates a set of keycodes of what exactly to send down the USB wire to the OS.
If you configure QMK Firmware to say that Key(1,1) is the letter "a", whenever you hit Key(1,1), it will send the letter "a" (scancode 0x04) down the USB wire.
There are some keys and that combinations which don't get sent down the USB wire at all. For example, Fn keys are typically used to switch between virtual "layers". This means that if you configured it, Fn + Key(1,1) could now send the letter "z" (scancode 0x1D). Now, when you hit Fn + Key(1,1), it will send the letter "z" (scancode 0x1D) down the USB wire. It will not send the Fn key, because the Fn key only matters to QMK firmware, and not the OS.
When you press the Fn + D keys, the QMK Firmware interprets this as change RGB Setting. Even though you may be a part of pcmasterrace, the OS does not know anything about RGB keyboards and lighting. Also, there is no RGB scancode in the USB HID protocol defining "change RGB". Therefore pressing the Fn + D keys sends nothing down USB to the OS.
Since Change RGB isn't happening on the OS, and it only exists inside your keyboard, Autohotkey cannot send the right set of keystrokes to replicate the functionality. The only way to make changes to the default settings in the keyboard is to make and flash your own custom QMK firmware.
As the others stated, the Fn+D and Fn+G functions are totally handled inside the keyboard package, with no information passing to or from the PC side, making it impossible to readily insert a PC script routine in between.
However, keyboard mechanical switches are perhaps the simplest circuit in the world; with a couple of jump wires and a microcontroller (MCU), you can simply override any finger movement. Now, if that MCU is handled correctly, it may be controlled by PC-side software such as AHK, allowing you to accomplish your aim.
I'm currently learning the workings of an operating system and would like to verify if my knowledge is correct on the steps taken during an interrupt. Trying to relate to something very familiar, here's what I think would happen when I press Alt+Tab to switch programs:
An interrupt is generated by the hardware (keyboard): intr flag of the CPU is set via system bus from keyboard controller
CPU saves the current process state to the PCB to pass control to the interrupt (is kernel mode entered here?)
CPU reads interrupt to index the interrupt service routine via the interrupt vector stored in memory
The interrupt service routine (along with the interrupt details such as which keys got pressed) is processed (at which point I assume user sees the program being switched)
The interrupt is complete (mode bit set back to 1 indicating user mode now?), PCB of the interrupted process gets restored and resumes running.
Are there steps that I'm missing or did not describe correctly?
There are many many factors here that you need to take in to consideration. For example:
- Is the keyboard on the ISA bus and is of an PC/AT style keyboard?
- If so, is the PIC (programmable Interrupt Controller) involved?
- Is the keyboard a USB keyboard device?
- Is the interrupt an older style PIC, newer style APIC, or a latest style MSI interrupt?
There are many things to consider. However, to try to explain what probably happens, I will assume you have an AT style keyboard attached to the keyboard controller port (PS2 style maybe), you have an older style PIC, and a simplified single- or multi-tasking system.
What could happen when the user presses the Alt key and then the Tab key:
- The CPU is interrupted (hence the name) by the PIC
- The CPU "jumps" to the interrupt request routine (IVT, exception, whatever)
- The routine reads from the keyboard. A single byte is read which happens
to be (part of) the make code for the alt key.
- the routine then places this make code in some sort of input buffer the
operating system has set up for it, whether it be part of the OS or part
of the keyboard driver.
- the interrupt is acknowledged via the PIC (this step can and usually is
before the previous step)
- the routine gives up the CPU (iret instruction)
The process is repeated three more times (assuming a make code and a break code are single byte codes. They can be multiple-byte codes). An interrupt is created on a make and a break key. A make key is when a key is pressed. A break key is when a key is released. i.e:
- make (Alt Down)
- make (Tab Down)
- break (Tab Up)
- break (Alt Up)
You see, there are four interrupts that take place (again assuming single-byte codes), four times the interrupt routine is called, and four times the CPU is interrupted to handle the key press(es) and release(es).
As for the task switching, via an ALT-TAB key combination, this is usually not done within the interrupt handler. The OS will see the Make (or Break) key of the Tab, it will check the status of the shift state (which should include the Alt key) and go from there.
It the keyboard is a USB style keyboard, then you have a totally different process of events. The USB keyboard does not interrupt the CPU as shown above. The keyboard has an Interrupt Pipe that periodically checks to see if there is a key make or break sequence. The OS will give up a time slice to the USB driver, just enough time to check this Interrupt Pipe. However, please note that an Interrupt (PIC, MSI, or other) is not triggered for USB keyboards, unless the USB driver specifies an interrupt should happen at end of frame. Note though that this interrupt is not fired because of the key press (or release), it is triggered because of the end of frame of the USB has taken place.
There is a lot that takes place because of a simple key press and release. I would study on what style of keyboard you wish to program for, what style of interrupt controller, CPU, etc., and go from there.
If you wish, I wrote a series of books on this subject where I explain what happens for both an ISA style keyboard and a USB style keyboard. It has been a very enjoyable hobby and I hope you find the same joy in yours.
I am trying to use org-mode and whenever I press Crtl+return emacs does C-J instead. I know this because when I use c-h k and then press crtl+return, emacs shows:
"It is bound to C-j."
Is there anyway I can make it register ctrl+return so I can insert headings?
I am using emacs23 through the terminal on ubuntu 12.04 x64. When I do this on my windows machine it does insert a new heading.
Possibly. As #phils says, C-Enter is usually not a valid sequence for the vast majority of terminal emulators. This is because when you press a key, or key combination, the terminal sends a sequence of characters to the relevant application. Pressing a sends a, whereas Enter sends CR - carriage return (otherwise known as ^M, \r or \015).
What sequences are actually implemented in modern terminals is mostly just a hang-over from the earlier, physical, terminals that they emulate (notably the VT-100). These machines didn't allow the use of Ctrl in conjunction with every key, such as the function keys, for example, so C-F1 was not possible and didn't have an escape sequence defined. Similarly, there is no control sequence for C-Enter, so when you press it, the terminal ignores the Ctrl and just sees the Enter.
You may, however, be able to define your own escape sequences in your terminal, which you can then bind to the correct key combinations in emacs. See here, for example. I was able to use this method to be able to use C-Enter. Unfortunately, this is still a bit of a pain, as it requires a lot of configuration and you may still be unable to use some sequences (C-M-% doesn't work in konsole for me). As with #phils, I've taken to using the GUI, but I'd love to have better integration with my terminal.
That's not a valid sequence for most terminals, I'm afraid, so they simply can't send it to Emacs.
If you run GUI Emacs instead, the key bindings will work.
Thomas Dickey's xterm is the only terminal software I know of which can (I think) support all the normal Emacs bindings. If you're okay with compiling that, then you could try it with the following .Xdefaults-(hostname) (or .Xresources if you re-merge after editing) to get basic support working:
XTerm*metaSendsEscape: true
XTerm*modifier: meta
XTerm*modifyOtherKeys: 1
You actually need XTerm*modifyOtherKeys: 2 to fully extend the sequences (otherwise you still can't type the likes of C-M-%), but by default that setting will break most key sequences, and right now I couldn't tell you how to configure things correctly for that setting (the only example I've seen -- xterm-extras.el as mentioned on the wiki and available in the easymacs download -- didn't work for me).
I mostly use GUI Emacs, but I'd love to get this working properly, so if anyone has had success with xterm-extras.el or similar, please do speak up.
If you're willing to install an Emacs package and configure your terminal, I wrote an Emacs package which can teach Emacs and terminals how to properly recognize all PC keyboard keys and modifier key combinations:
https://github.com/CyberShadow/term-keys
Its default configuration enables encoding the CtrlReturn combination, which allows Emacs to distinguish it from CtrlJ.
When I open files with emacs it adds 12;rgb:1c1c/1c1c/1c1c on the top. How can I prevent this?
I have installed emacs on a clean reinstalled debian system.
Emacs: GNU Emacs 24.4.1
Terminal Emulator: MobaXterm Personal Edition v7.7
System (local): Windows 7 Ultimate
System (remote): Debian 8.0 "jessie" stable
As noted, "MobaXterm" is not "xterm". According to its webpage it is
Based on PuTTY/MinTTY with antialiased fonts and macro support
Lacking a detailed change history, and the problem reported by the OP, it seems that MobaXterm is based on PuTTY from a while back, and does not implement all of the control sequences which PuTTY does, much less those of xterm.
The particular sequence which is not recognized (referring to XTerm Control Sequences) may be this:
OSC Ps ; Pt ST
OSC Ps ; Pt BEL
...
Ps = 1 2 -> Change text cursor color to Pt.
That is part of a group of controls predating ANSI color support in xterm, referred to as dynamic colors.
Based on comments in other places, it seems that the problem could lie within the OP's Emacs configuration, by using scripts which do an ad hoc test of TERM to decide if it can do colors, rather than inspecting the terminal capabilities. See Terminal emacs colors only work with TERM=xterm-256color where someone worked around this problem by modifying their init.el to add special cases for rxvt and xterm.
Emacs of course is capable of doing colors in different terminals. See emacs colors based on $TERM environment variable for comments. And TERM=xterm on Debian has provided color for quite a while. So in a typical configuration, color should "just work".
However, there are different ways to configure Emacs. Attempting to reuse some 256-color script can fall into the hole dug by developers who assume that every terminal is just like the one in front of them. See the Emacs wiki page X Term Colors for an example.
!! SOLVED IN MOBAXTERM VERSION 8.2 !!
Looks like your terminal settings are out of sync. The settings of your terminal need to agree with the termcap/terminfo settings on the server. Try to set the TERM variable in the shell on the server to a value which better matches the terminal emulation capabilities of your terminal (common values are xterm, xterm-color, vt520, and vt102) or correspondingly change the settings of the terminal to match the current TERM value. (If the terminal is buggy, you may need some trial and error to find a mode which works well for you.)
VT220 works fine; Edit Session / Terminal Settings / Type: vt220
I am having a problem when trying to print 3rd level keyboard symbols in Eclipse IDE with AltGr + [1-9] buttons. Specifically I am using Lithuanian keyboard layout and whenever I press AltGr + number I get both 1st level and 3rd level symbols printed. Eg., if I hit AltGr + 1, I get the following two symbols printed:
ą1
('ą' is the 1st level symbol, while '1' is the 3rd level one)
For AltGr + 2 it's as follows:
č2
('č' is the 1st level symbol, while '2' is the 3rd level one)
and etc
I have tried searching if there were AltGr + number or Ctrl + Alt + number key shortucts but could not find any.
I have tested some other keyboard layouts and found that on other keyboards the 3rd level works as usual and prints only one symbol. However, I would also like to note that with the Lithuanian layout AltGr + E works completely fine and prints a single € symbol.
It is also worth noting that I have encountered the same problem on different machines running Windows 7, Windows XP and Red Hat Linux. This may suggest that a solution must be found inside eclipse. However, I have failed to do that and I would appreciate if somebody could help me to solve this problem.
I think you should file a bug with Eclipse.
Alternatively, you could try to debug Eclipse yourself. The SWT library is the gateway to low-level methods that interface with the OS and handle keypresses and the like. If you looked at org.eclipse.swt.Control, you could find places to put breakpoints.
To debug Eclipse, you need the Eclipse SDK (which comes bundled with the RCP/RAP edition, i.e. http://www.eclipse.org/downloads/packages/eclipse-rcp-and-rap-developers/indigor). Then you create an Eclipse Application launch target and launch it in debug mode.
But file a bug!